Bug #5863
closedfile:/// URIs do not resolve correctly
0%
Description
The following returns file:/home/pumba/
where I would expect file:///home/pumba/
.
As a result, document('file:/home/pumba/file.xml')
cannot find the document, whereas document('file:///home/pumba/file.xml')
can.
SaxonJS returns the expected result.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:math="http://www.w3.org/2005/xpath-functions/math"
xmlns:map="http://www.w3.org/2005/xpath-functions/map"
xmlns:array="http://www.w3.org/2005/xpath-functions/array"
exclude-result-prefixes="#all"
version="3.0">
<xsl:mode on-no-match="shallow-copy"/>
<xsl:output method="html" indent="yes" html-version="5"/>
<xsl:template match="/">
<xsl:value-of select="resolve-uri('..', 'file:///home/pumba/WebRoot/')"/>
</xsl:template>
</xsl:stylesheet>
Updated by Martin Honnen about 1 year ago
Just curious, on what platform does the document('file:/home/user/file.xml')
access fail? I have tried with Linux and it doesn't fail, the URI is resolved as you describe but the document can be accessed by the document
function.
Updated by Martynas Jusevicius about 1 year ago
My bad! document('file:/home/user/file.xml')
works...
Updated by Michael Kay about 1 year ago
I find the Wikipedia article
https://en.wikipedia.org/wiki/File_URI_scheme
more helpful than the RFCs, though RFC 8089 does clear up a lot of the confusion that existed previously.
Both file:///x/y/z and file:/x/y/z are legal and widely accepted, but the precise details of what works depends on the software you are using to retrieve the resource (which will be somewhere on the stack well below the Saxon level).
Updated by Norm Tovey-Walsh about 1 year ago
In the second comment you say
My bad! document('file:/home/user/file.xml') works...
Does that mean your problem has been resolved?
Updated by Norm Tovey-Walsh about 1 year ago
- Status changed from New to Rejected
No problem. It's an easy bug report to resolve in that case :-)
Please register to edit this issue