xsl:include fails after upgrading PHP version; is libxml/libxslt version mismatch the issue?

Question

I'm running Windows XP with the precompiled PHP binaries available from windows.php.net. I upgraded from PHP 5.2.5 to PHP 5.2.16, and now the xsl:includes in some of my stylesheets stopped working. Testing each version in succession, I discovered that it worked up through 5.2.8 and does not work in 5.2.9+. I now get the following three errors for each xsl:include.

Warning: XSLTProcessor::importStylesheet() [xsltprocessor.importstylesheet]: I/O warning : failed to load external entity "file%3A/C%3A/path/to/included/stylesheet.xsl" in ... on line 227

Warning: XSLTProcessor::importStylesheet() [xsltprocessor.importstylesheet]: compilation error: file file%3A//C%3A/path/to/included/stylesheet.xsl line 36 element include in ... on line 227

Warning: XSLTProcessor::importStylesheet() [xsltprocessor.importstylesheet]: xsl:include : unable to load file%3A/C%3A/path/to/included/stylesheet.xsl in ... on line 227

I presume this is because it cannot find the specified file. Many of the includes are in the same directory as the stylesheet being transformed and have no directory in the path, i.e. <xsl:include href="fileInSameDir.xsl">. Interestingly, in the first and third errors, it is displaying the file:// protocol with only one slash instead of the correct two. I'm guessing that's the problem. (When I hard-code a full path using "file:/" it fails, but when I hard-code a full path with "file://" it works.) But what could cause that? A bug in libxslt/libxml? I also found an apparent version mismatch between libxml and the version of libxml that libxslt was compiled against.

5.2.5
libxml Version => 2.6.26
libxslt compiled against libxml Version => 2.6.26

5.2.8

libxml Version => 2.6.32
libxslt compiled against libxml Version => 2.6.32

=== it breaks in versions starting at 5.2.9 ===
5.2.9
libxml Version => 2.7.3
libxslt compiled against libxml Version => 2.6.32

5.2.16
libxml Version => 2.7.7
libxslt compiled against libxml Version => 2.6.32

Up until PHP 5.2.9, libxslt was compiled against the same version of libxml that was included with PHP. But starting with PHP 5.2.9, libxslt was compiled against an older version of libxml than that which was included with PHP. Is this a problem with the distributed binaries or just a coincidence?

To test this, I imagine PHP could be built with different versions of libxml/libxslt to see which combinations work or don't. Unfortunately, I'm out of my element in a Windows world, and building PHP on Windows seems over my head.

Regrettably, I've been thus far unable to reproduce this problem with an example outside my app, so I'm struggling to narrow it down and can't submit a specific bug.

So, do you think it is caused by

• a version mismatch problem in the distributed binaries?
• a bug introduced in PHP 5.2.9?
• a bug introduced in libxml 2.7?
• something else?

I'm stumped. Any thoughts that could point me in the right direction are greatly appreciated. Thanks.

Answer 1

This has been submitted as PHP bug #53965.

Proper usage of the file:// protocol dictates that full Windows paths must have a third consecutive slash to imply localhost (i.e., file:///C:/path). My application incorrectly uses two slashes (i.e., file://C:/path). Presumably, the parser simply tokenized the URI without full error checking and then passed along the recombined string to the XSLT processor, resulting in the appearance of "file:/C:/path".

Two options to solve my problem:

1. add that third slash, or
2. remove the "file://" protocol entirely, since they're just local files

Even though my code was ultimately incorrect, my confusion thus stemmed from the fact that no errors were generated that noted my invalid URI and that the initial file loaded successfully anyway. Either both files should load, or both files should not load -- not one loads and one doesn't, as was the case.