Project

Profile

Help

Bug #4337

closed

base-uri() call is incorrectly encoding the resulting URI.

Added by Jorge Williams over 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2019-10-09
Due date:
% Done:

0%

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

Description

Our application requires the base-uri in order to create links. The URI may contain query parameters:

for example : http://localhost:9090/path/to/app?param1=1&param2=2&param3=3

We get to the URI like this...

   <xsl:template match="/" >
       <xsl:variable name="url" select="base-uri(.)"/>
     .
     .
     .

The result that we get for $url is

http://localhost:9090/path/to/app?param1=1&amp;param2=2&amp;param3=3

We don't think this correct. Replacing & with an entity should be something that happens during serialization.

We expect the result to be:

 http://localhost:9090/path/to/app?param1=1&param2=2&param3=3

As a workaround we're currently doing this:

 <xsl:template match="/">
       <xsl:variable name="url" select="replace(base-uri(.), 'amp;','')" />

Thanks

Actions #1

Updated by Michael Kay over 4 years ago

How was the base URI set up in the first place? My suspicion would be that the &amp; substrings are present in the base URI supplied to Saxon, rather than being something that the base-uri() function has added.

Actions #2

Updated by Jorge Williams over 4 years ago

We simply type in the URI into the location bar in Safari.

Actions #3

Updated by Michael Kay over 4 years ago

And how do you invoke the transformation?

Actions #4

Updated by Jorge Williams over 4 years ago

We start with a server side transformation that sets up the HTML wrapper to bootstrap SaxonJS, the source document is dynamically generated and the URI is in an atom link.

So on the server side we do something like this:

<xsl:template expand-text="no" name="xsl:initial-template">
        <xsl:variable name="self" select="/*/atom:link[@rel='self']/@href"/>

 <html lang="en">
            <head>
                <script src="/resources/Saxon-JS/SaxonJS.js"></script>
                <script> window.onload = function() { SaxonJS.transform({ stylesheetLocation: "/resources/xsl/document.sef", sourceLocation: "<xsl:value-of select="$self"/>" }); } </script>
.
.
.
.

</xsl:template>
Actions #5

Updated by Michael Kay over 4 years ago

So -- conjecture -- the HTML that you're generating server side will be serialized and the "sourceDocument" URL contained in the HTML has been ampersand-escaped. But when it's read by the HTML parser, the contents of a script element don't get unescaped.

The HTML serialization method isn't supposed to apply escaping to the contents of a script element, precisely because the HTML parser doesn't apply unescaping. But perhaps you didn't generate the document using the HTML output method?

Actions #6

Updated by Jorge Williams over 4 years ago

Confirmed that "sourceDocument" is ampersand-escaped by server side transform:

<script src="/resources/Saxon-JS/SaxonJS.js"></script><script> window.onload = function() { SaxonJS.transform({ stylesheetLocation: "/resources/xsl/document.sef", sourceLocation: "http://localhost:8080/test/?bar=true&amp;foo=true" }); } </script>

Setting output method to HTML...

 <xsl:output method="html" />

... had no effect on the encoding of the "sourceDocument" url.

Actions #7

Updated by Michael Kay over 4 years ago

Two explanations come to mind for the contents of <script> being escaped:

(a) the script element is in a namespace, e.g. the XHTML namespace

(b) the serialization isn't actually being done by the XSLT serializer (for example, the stylesheet output is going to a DOM, which is then serialized using the DOM serializer).

Has the serializer added a <meta> element with ContentType and encoding? That's usually a good indicator of whether it was produced by the XSLT serializer.

Actions #8

Updated by Jorge Williams over 4 years ago

Removing

xmlns="http://www.w3.org/1999/xhtml"

from the top of the server side stylesheet resolved the issue.

Thank you!

Actions #9

Updated by Michael Kay almost 4 years ago

  • Status changed from New to Closed

Please register to edit this issue

Also available in: Atom PDF Tracking page