Project

Profile

Help

Bug #5074

"XML Parsing Error" when loading SEF file with Saxon-JS 2.3

Added by Martynas Jusevicius about 2 months ago. Updated 11 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2021-09-01
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
2
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

Not exactly sure that is the reason, but the upgrade from 2.2 to 2.3 coincides with this error message appearing when SEF is being loaded:

XML Parsing Error: not well-formed
Location: https://localhost:4443/static/com/atomgraph/linkeddatahub/xsl/client.xsl.sef.json
Line Number 1, Column 1: client.xsl.sef.json:1:1
SEF generated by Saxon-JS 2.3 at 2021-09-01T13:32:15.961+02:00 with -target:JS -relocate:true

Execution seems to proceed normally after that. I wonder if there have been changes in this area?

History

#1 Updated by Martynas Jusevicius about 2 months ago

To be clear: I'm using the browser, and the log above is from the console log.

#2 Updated by Martynas Jusevicius about 2 months ago

It looks like 2.3 began using conditional requests (If-Modified-Since/If-None-Match) when requesting SEF? Which makes total sense for performance reasons, but since a 304 Not Modified response does not include a Content-Type header, maybe this messes up the media type recognition somehow?

Saxon-JS 2.3

GET /static/com/atomgraph/linkeddatahub/xsl/client.xsl.sef.json HTTP/1.1
Host: localhost:4443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://localhost:4443/
Connection: keep-alive
Cookie: _ga=GA1.1.828629977.1584086266; LinkedDataHub.first-time-message=true; _octo=GH1.1.128689066.1607637748
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
If-Modified-Since: Wed, 01 Sep 2021 14:11:02 GMT
If-None-Match: W/"7084893-1630505462650"
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 304 
Server: nginx/1.21.0
Date: Wed, 01 Sep 2021 14:17:38 GMT
Connection: keep-alive
ETag: W/"7084893-1630505462650"

Saxon-JS 2.2

GET /static/com/atomgraph/linkeddatahub/xsl/client.xsl.sef.json HTTP/1.1
Host: localhost:4443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: https://localhost:4443/?uri=https%3A%2F%2Flocalhost%3A4443%2F
Cookie: _ga=GA1.1.828629977.1584086266; LinkedDataHub.first-time-message=true; _octo=GH1.1.128689066.1607637748
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
HTTP/1.1 200 
Server: nginx/1.21.0
Date: Wed, 01 Sep 2021 14:30:07 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Accept-Ranges: bytes
ETag: W/"7070035-1630012354000"
Last-Modified: Thu, 26 Aug 2021 21:12:34 GMT
vary: accept-encoding
Content-Encoding: gzip

#3 Updated by Norm Tovey-Walsh about 2 months ago

Interesting. We did some work in 2.3 to improve the way Accept: headers are sent. (Bug #5017)

I suppose this could be an unintended consequence, but it's hard to imagine how we didn't stumble over this ourselves in testing.

Is there any chance you can trim your application down to a test case that demonstrates the problem as your encountering it?

#4 Updated by Martin Honnen about 2 months ago

I see the parsing error with Firefox but not Chrome in https://martin-honnen.github.io/xslt/2021/saxon-js-key-test2.html which uses Saxon-JS 2.3 while neither Chrome nor Firefox show the parsing error with https://martin-honnen.github.io/xslt/2021/saxon-js-key-test1.html which uses Saxon-JS 2.2. Chrome, however, doesn't do me the favour to use the 304 header, it just uses its disk cache. But with Firefox I indeed get an error like

XML Parsing Error: not well-formed
Location: https://martin-honnen.github.io/xslt/2021/saxon-js-key-test1.sef.json
Line Number 1, Column 1:

for the test case at https://martin-honnen.github.io/xslt/2021/saxon-js-key-test2.html using Saxon-JS 2.3.

#5 Updated by Martynas Jusevicius about 2 months ago

I can confirm that I also observe this behavior in Firefox.

#6 Updated by Martynas Jusevicius about 1 month ago

Any updates on this? The code seems to work fine, but having errors like this in the console is not ideal...

#7 Updated by Norm Tovey-Walsh about 1 month ago

No progress yet, I'm afraid. There's a lot going on just at the moment. I'll make sure we get this sorted out as quickly as we can.

#8 Updated by Martynas Jusevicius 11 days ago

Ping again :) Is Saxon-JS on a lower priority now?

#9 Updated by Norm Tovey-Walsh 11 days ago

No, not at all. But we're a small team and big releases, like SaxonCS, tend to consume all available cycles. Debbie and I are on the hook for a few other deliverables, short term, but then we'll look at fixing bugs and doing an other Saxon-JS release as soon as possible.

Sincere apologies for the delay. I promise it's a high priority!

Please register to edit this issue

Also available in: Atom PDF Tracking page