Project

Profile

Help

Bug #5017

Fix Accept header value sent by document()

Added by Martynas Jusevicius 4 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
API
Sprint/Milestone:
-
Start date:
2021-06-03
Due date:
% Done:

100%

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

Description

This is related to #4748 but a different issue.

As far as I can see, content negotiation is broken as on document() Saxon-JS makes HTTP requests using an Accept: */* header. This is a catch-all value that can lead to any media type being returned.

I think there should be an explicit preference for XML formats, which can be achieved using weights.

I would suggest such a header value: Accept: text/xml, application/xml;q=0.9, application/xhtml+xml;q=0.8, */*;q=0.7. It might be possible to improve/generalize it further. Ideally it should be configurable.

History

#1 Updated by Debbie Lockett 3 months ago

  • Status changed from New to In Progress
  • Assignee set to Debbie Lockett

I believe you are running in the browser rather than on Node.js?

In the browser, for asynchronous loading, you generally will be using ixsl:schedule-action/@document to load a document before a call to document(). However there is no mechanism for specifying content negotiation here. (Updating ixsl:schedule-action to allow this would be complicated; and we can't just amend the internal implementation as suggested because we do want to use this mechanism for loading a variety of file types.)

Another option (available on Node.js as well as the browser) is to use SaxonJS.getResource, and then supply the preloaded resources for the SaxonJS.transform using the documentPool (or textResourcePool) option. Feature #4748: Option to supply Accept header in SaxonJS.getResource() should allow the Accept header to be supplied; but I'm reopening that issue, because it looks like the fix was incomplete.

In the meantime, could you rework your code to use ixsl:schedule-action/@http-request instead? Here you can specify the full HTTP request, including the headers. I guess a problem might be that the response document will not be in the standard document pool, so you won't be able to just use document() as before. It is just returned in the body of the HTTP response map. (See https://www.saxonica.com/saxon-js/documentation/index.html#!development/http)

#2 Updated by Martynas Jusevicius 3 months ago

Yes running in the browser.

This issue mostly concerns templates shared between the server-side (Saxon-HE) and the client-side (Saxon-JS). Where Saxon-HE succeeds loading XML using document(), Saxon-JS fails due to the underspecified Accept header.

ixsl:schedule-action is not applicable if the template has to work on the server-side; the documentPool helps but some URLs might not be known in advance (at Saxon-JS initialization time).

Would it be hard to change the default Accept header value? :) Or set it to the same that Saxon-HE sends?

#3 Updated by Debbie Lockett about 1 month ago

  • Category set to API
  • Status changed from In Progress to Resolved
  • Fix Committed on JS Branch 2 added

Code updated in BrowserPlatform.js (in asyncGet and readFile methods), to update the default Accept header as suggested. We now use Accept: application/xml, text/xml;q=0.9, application/xhtml+xml;q=0.8, */*;q=0.7.

Browser tests API/document01 and document02 added (testing both synchronous and asynchronous document fetching).

#4 Updated by Debbie Lockett about 1 month ago

  • % Done changed from 0 to 100
  • Fixed in JS Release set to Saxon-JS 2.3

Bug fix applied in the Saxon-JS 2.3 maintenance release.

#5 Updated by Debbie Lockett about 1 month ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF Tracking page