Bug 5609 – XSLT document() doesn't handle relative paths

• Status: VERIFIED
• Resolution: FIXED
• Component: XML

[Alastair Rankine]

(As posted to http://webkit.opendarwin.org/blog/?p=32#comments)

The document() function in XSLT doesn't handle relative pathnames. Enclosed is a simple test case which 
tries several different methods to extract some information from a document, but only the full path (with 
file:// prefix) works. I'm not sure of the strict legality of the test case, but other XSLT engines (eg xsltproc) 
handle this situation well.

[Alastair Rankine]

Created attachment 4578 [details]
Zipfile containting sample stylesheet and test document

[Alastair Rankine]

Forgot to mention this is WebKit 416.12, Safari 2.0.2

[Alexey Proskuryakov]

Created attachment 5427 [details]
proposed fix

[Eric Seidel (no email)]

Comment on attachment 5427 [details]
proposed fix

I talked with ap on irc.  I'm dubious about the ascii() to utf8() change, as it
was my impression that all libxml2 apis which specify const char * take a
latin1 string, those which specify xmlChar * take a utf8 string.  But I could
be wrong.  I asked him to provide a test case for this change.

Darin also pointed out a problem with ap's URL manipulation on irc, so r- this
one.

[Darin Adler]

Comment on attachment 5427 [details]
proposed fix

The relative URL resolution should use the KURL constructor that takes a base
URL and a relative string. There should not be the code to check isValid() and
the code that calls setPath.

Otherwise looks good.

[Darin Adler]

I think the UTF-8 change is correct, but I'd like to see a test case that fails with ascii() and succeeds with 
utf8() to prove it.

[Alexey Proskuryakov]

Created attachment 5430 [details]
non-ASCII paths test

A test with non-ASCII paths. Shows that utf8() is a correct choice for the base
URL, but resources that have non-ASCII names still cannot be loaded. Since
xsltproc has the same problem (and Firefox doesn't), this sounds like a bug in
libxslt.

[Alexey Proskuryakov]

Oops, I spoke too fast - this test works with either utf8() or ascii() - because xmlDocPtrForString() gets 
percent-encoded ASCII URLs from its caller.

Now, there may be issues related to which encoding was used to form the URL, but since libxslt seems to 
have problems here, there's probably not much sense in investigating this right now (but I'll file a separate 
bug to track this).

[Alexey Proskuryakov]

Created attachment 5432 [details]
updated patch

[Eric Seidel (no email)]

Comment on attachment 5432 [details]
updated patch

(const char *)xmlNodeGetBase(((xsltTransformContextPtr)ctxt)->document->doc,
((xsltTransformContextPtr)ctxt)->node)
Could be made slightly clearer using a local variable.

Otherwise it looks totally fine.  I don't have quite enough xlst-fu to
understand your test case, but I trust you.

[Alastair Rankine]

Verified against 06-01-2006 nightly build. Test case works nicely, thanks.