Project

Profile

Help

Bug #6107

closed

Can't use namespaced attributes on the root element of the body of a SaxonJS http-request

Added by Ben Weaver over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Category:
IXSL extensions
Sprint/Milestone:
-
Start date:
2023-06-29
Due date:
% Done:

100%

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

Description

Using SaxonJS 2.3 / SaxonJ-EE 11.3, we encountered what appears to be a bug in the http-request code.

Trying to make an http-request with an xml body, on which - at root element level - there is a namespaced attribute, e.g.

<xsl:variable name="body">
    <node attrNs:myAttr="hello" xmlns:attrNs="foo" />
</xsl:variable>

The http request that is sent has a body like this, i.e. with the namespace declaration duplicated.

<node attrNs:myAttr="hello" xmlns:attrNs="foo" xmlns:attrNs="foo" />

This seems to occur no matter how the body is constructed, with the namespace declared on it vs only in the stylesheet root; with the prefix in exclude-result-prefixes or not; with the attribute given as a literal, or using xsl:attribute with a namespace attribute, or not, etc. etc.

Namespaced attributes that are not on the root node do not seem to trigger this problem (unfortunately our schema does not permit us to use this workaround).


I was able to make a minimal reproduction using the HelloWorldJS project, simple replacing the click handler and adding a template to catch the response (it doesn't matter that there is no endpoint to receive the request - the malformed payload is visible on the request)

  <xsl:template mode="ixsl:onclick" match="button[@id='pushme']">
    <xsl:variable name="body">
      <node attrNs:myAttr="hello"/>
    </xsl:variable>
    <xsl:variable name="request" as="map(*)">
      <xsl:map>
        <xsl:map-entry key="'href'" select="'http://localhost:9000/test'"/>
        <xsl:map-entry key="'method'" select="'POST'"/> <!-- or PUT, or PATCH... -->
        <xsl:map-entry key="'media-type'" select="'application/xml'"/>
        <xsl:map-entry key="'headers'" select="map{ 'Content-Type': 'application/xml' }"/>
        <xsl:map-entry key="'body'" select="$body"/>
      </xsl:map>
    </xsl:variable>
    <ixsl:schedule-action http-request="$request">
      <xsl:call-template name="debug"/>
    </ixsl:schedule-action>
  </xsl:template>

  <xsl:template name="debug">
    <xsl:result-document href="#button">
      <h2><xsl:value-of select="?status"/></h2>
      <pre><xsl:value-of select="?body"/></pre>
    </xsl:result-document>
  </xsl:template>

Thanks Ben

Actions #1

Updated by Martin Honnen over 1 year ago

The current SaxonJS release is 2.5. Can you try with that instead of 2.3?

I have tried at https://martin-honnen.github.io/xslt/2023/http-request/test1.html with a SaxonJS 2.5 compiled stylesheet and SaxonJS 2.5 client-side to reproduce the problem but the browser (tested with Chrome) show the request payload as <data foo:attr1="value1" xmlns:foo="http://example.com/foo"/> for me.

Actions #2

Updated by Ben Weaver over 1 year ago

Thanks Martin. I get the same behaviour with 2.5 when using Safari, but indeed it works fine with Chrome. So a Safari bug maybe.

Actions #3

Updated by Martin Honnen over 1 year ago

Yes, this looks like a bug with Safari, not sure whether in their browser APIs or in some way in SaxonJS's code base.

Anyway, Norm or Debbie, the request Safari (for me Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.1 Safari/605.1.15) sends is indeed

<data foo:attr1="value1" xmlns:foo="http://example.com/foo" xmlns:foo="http://example.com/foo"/>

Initiator is SaxonJS2.rt.js:17554, at least that is what the Safari development tools say, but I am not sure that is the line where the response from the server is handled or the code where the request is constructed.

Actions #4

Updated by Norm Tovey-Walsh over 1 year ago

Anyway, Norm or Debbie, the request Safari (for me Mozilla/5.0 (Macintosh; Intel Mac OS X
10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.1 Safari/605.1.15) sends is
indeed

Thanks for that pointer. I’ve been doing a bit of refactoring in SaxonJS
to support some new features. As soon as it builds and runs again :-),
I’ll see if I can reproduce this.

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Actions #5

Updated by Debbie Lockett about 1 year ago

  • Category set to IXSL extensions
  • Status changed from New to Resolved
  • Assignee set to Debbie Lockett
  • Applies to JS Branch 2 added
  • Fix Committed on JS Branch 2 added

Problem reproduced, and unit test added (browser/iss6017).

Fix committed on saxonjs2 branch in BrowserPlatform.makeHttpRequest() method: to serialize the request body supplied to the XMLHttpRequest.send() call ourselves, rather than supplying a document node and relying on the browser to do it. This avoids the apparent bug in the Safari serialization.

(Note that the fix is not required on the trunk development branch, because there we are already serializing the request body having switched to use the Fetch API, rather than XMLHttpRequest.)

Actions #6

Updated by Debbie Lockett about 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to SaxonJS 2.6

Bug fix applied in the SaxonJS 2.6 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page