Bug #5017

Fix Accept header value sent by document()

Added by Martynas Jusevicius 15 days ago. Updated 9 days ago.

In Progress
Start date:
Due date:
% Done:


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


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.


#1 Updated by Debbie Lockett 9 days 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!development/http)

#2 Updated by Martynas Jusevicius 9 days 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?

Please register to edit this issue

Also available in: Atom PDF Tracking page