"XML Parsing Error" when loading SEF file with Saxon-JS 2.3
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?
#2 Updated by Martynas Jusevicius about 2 months ago
It looks like 2.3 began using conditional requests (
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?
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"
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.
#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