[PHP-BUG] Bug #60826 [NEW]: raw POST data missing with chunked encoding, FastCGI
From: Operating system: Windows XP PHP version: 5.3.9 Package: CGI/CLI related Bug Type: Bug Bug description:raw POST data missing with chunked encoding, FastCGI Description: When a POST is sent with the header "Transfer-Encoding: chunked" and PHP 5.3 is running via FastCGI, $HTTP_RAW_POST_DATA is not set. In IIS, the receiving PHP process simply hangs and does not execute at all. If chunked encoding is not set, it executes successfully and $HTTP_RAW_POST_DATA is populated. Comparing ISAPI to FastCGI (using PHP 5.2 which has both implementations), PHP ISAPI works fine with "Transfer-Encoding: chunked" but PHP FastCGI does not. This issue also occurred running Linux/Apache with PHP 5.3 FastCGI. In that scenario, the PHP process did not completely hang, but $HTTP_RAW_POST_DATA and php://input were empty when the script executed. Test script: --- Two files, postsend.php and postreceive.php, can be found within the question here: http://stackoverflow.com/questions/8899239/http-raw-post-data-not-being-populated-after-upgrade-to-php-5-3 Expected result: $HTTP_RAW_POST_DATA and the php://input stream should contain the raw binary data that was sent in the POST. Actual result: -- On Windows/IIS, the PHP process hangs and does not execute. On Linux/Apache, the PHP process executes but $HTTP_RAW_POST_DATA and php://input are empty. -- Edit bug report at https://bugs.php.net/bug.php?id=60826&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60826&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60826&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60826&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60826&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60826&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60826&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60826&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60826&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60826&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60826&r=support Expected behavior: https://bugs.php.net/fix.php?id=60826&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60826&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60826&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60826&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60826&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60826&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60826&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60826&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60826&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60826&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60826&r=mysqlcfg
Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1 ID: 60826 Comment by: clarkwise at gmail dot com Reported by:clarkwise at gmail dot com Summary:raw POST data missing with chunked encoding, FastCGI Status: Assigned Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.3.9 Assigned To:ab Block user comment: N Private report: N New Comment: Since I am using Windows XP, I'm stuck using IIS 5.1. When I have the opportunity to try nginx w/ chunkin or IIS 7.5, I'll update with further details. Thanks. Previous Comments: [2012-03-01 08:31:15] a...@php.net @clarkwise at gmail dot com So could you confirm it works with nginx+chunkin? As well, it's was not hanging with IIS (v7.5) for me. Which IIS version do you have? [2012-02-09 19:17:27] a...@php.net I've additionally tested the two files on nginx with PHP as FCGI. The request simply doesn't go throught to PHP and nginx gives 401 back. I've attached gdb to the PHP and set a break in the accept loop - there was no reaction when using the two test files, but requests without data got down to PHP. So my conclusion were - apache simply ignores the request body where nginx gives a correct http status. Anyways, this has nothing to do with PHP. IIS, Apache and Nginx seem to have no implementation for chunked incoming body stuff, but they do handle that a different way. Btw. Nginx has the "chunkin" module for such actions. [2012-02-02 00:35:42] timo dot witte at googlemail dot com I have the same problem on my machine and can confirm this bug! i think this bug affects mod_spdy aswell, because it sends the POST data chunked! ( http://code.google.com/p/mod-spdy/issues/detail?id=22 ). ------------ [2012-01-20 21:15:54] clarkwise at gmail dot com Description: When a POST is sent with the header "Transfer-Encoding: chunked" and PHP 5.3 is running via FastCGI, $HTTP_RAW_POST_DATA is not set. In IIS, the receiving PHP process simply hangs and does not execute at all. If chunked encoding is not set, it executes successfully and $HTTP_RAW_POST_DATA is populated. Comparing ISAPI to FastCGI (using PHP 5.2 which has both implementations), PHP ISAPI works fine with "Transfer-Encoding: chunked" but PHP FastCGI does not. This issue also occurred running Linux/Apache with PHP 5.3 FastCGI. In that scenario, the PHP process did not completely hang, but $HTTP_RAW_POST_DATA and php://input were empty when the script executed. Test script: --- Two files, postsend.php and postreceive.php, can be found within the question here: http://stackoverflow.com/questions/8899239/http-raw-post-data-not-being-populated-after-upgrade-to-php-5-3 Expected result: $HTTP_RAW_POST_DATA and the php://input stream should contain the raw binary data that was sent in the POST. Actual result: -- On Windows/IIS, the PHP process hangs and does not execute. On Linux/Apache, the PHP process executes but $HTTP_RAW_POST_DATA and php://input are empty. -- Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1
ID: 60826
Comment by: clarkwise at gmail dot com
Reported by:clarkwise at gmail dot com
Summary:raw POST data missing with chunked encoding, FastCGI
Status: Assigned
Type: Bug
Package:CGI/CLI related
Operating System: Windows XP
PHP Version:5.3.9
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
Making the chunked request to a stock nginx 1.0.13 installation
on Ubuntu yields a "411 Length Required" message, but enabling
the ngx_chunkin module does indeed correctly serve the request
and populate php://input and $HTTP_RAW_POST_DATA.
This was done with both Ubuntu's distribution of
PHP 5.3.6 and the php5.4-201203221530 snapshot.
Previous Comments:
[2012-03-13 05:58:19] florian dot fernandez at navaho dot fr
First of all, the problem is still here with PHP 5.4 and Apache 2.4.1, I
previously made the mistake to precise the content-length in my headers.
So here is what I found. If you send chunked http request but do not send the
content-length (as we should do using HTTP 1.1 protocol) the body part of the
request is empty (php://input returns nothing). This result remains valid for
the following configuration where PHP runs via FastCGI :
PHP 5.3.10 - APACHE 2.4.1
PHP 5.3-201203101230 - APACHE 2.4.1
PHP 5.4 - APACHE 2.4.1
PHP 5.4-201203101230 - APACHE 2.4.1
The same configuration with PHP running as mod_php is fine, the body request is
available through php://input.
[2012-03-09 09:48:29] paj...@php.net
Try a snapshot please, 5.3.10 has nothing else but security fixes unrelated to
this issue.
[2012-03-09 09:33:06] florian dot fernandez at navaho dot fr
The problem seems to have been resolved with php 5.4.0 and apache 2.4.1. I
can't reproduce it with this configuration and chunked http requests are now
coming through to php now.
I am going to try with php 5.3.10 and apache 2.4.1 and give feedback on where
it goes.
[2012-03-05 11:46:27] florian dot fernandez at navaho dot fr
I forgot to mention that this is on a Linux system
[2012-03-05 10:08:17] florian dot fernandez at navaho dot fr
Same problem here. Apache 2.2.15 and PHP 5.3.10 running as FastCGI.
POST datas sent with "Transfer-encoding: chunked" are not received as they
should be. The raw request looks like this :
POST receiveChunk.php HTTP/1.1
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: keep-alive
Cache-Control: no-cache
Content-Length: 682668
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
3ff4
(here, the datas)
0
and the request as the receiving script sees it :
User-Agent: PECL::HTTP/1.7.2 (PHP/5.3.8)
Host: www.test.fr
Accept: */*
Pragma: no-cache
Connection: close
Cache-Control: no-cache
As you can see, the request body is empty.
However, this problem does not occur when PHP runs as mod_php under Apache.
Problem confirmed under PHP 5.3.8 and 5.3.9.
I don't know if that is a PHP bug and maybe the developers could confirm or not
that the request body are wrong before it reaches PHP. I think that it appears
to be a mod_fcgid bug and should be reported as one to Apache bug list.
Here are the scripts to reproduce the bug :
sendChunk.php :
'no-cache',
'Connection' => 'keep-alive',
'Cache-Control' => 'no-cache',
'Content-Length' => strlen($fileContentToUp) ,
'Transfer-Encoding' => 'chunked'
);
$options = array(headers => $header_array);
$r = new HttpRequest('receiveChunk.php', HTTP_METH_POST, $options);
$r->setContentType('text/html; charset=UTF-8');
$r->setBody($fileContentToUp);
$result = $r->send();
echo '$r->getRawRequestMessage() => ';
print_r($r->getRawRequestMessage());
echo "\n\n";
echo '$r->send()->getBody() => ';
print_r($r->send()->getBody());
echo "\n\n";
?>
receiveChunk.php :
'."\n";
print_r($HttpResponse->getRequestHeaders());
echo "\n\n";
echo 'http_get_request_body => '."\n";
print_r($HttpResponse->getRequestBody());
echo "\n\n";
?>
Hope that helps.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60826
--
Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1 ID: 60826 Comment by: clarkwise at gmail dot com Reported by:clarkwise at gmail dot com Summary:raw POST data missing with chunked encoding, FastCGI Status: Assigned Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.3.9 Assigned To:ab Block user comment: N Private report: N New Comment: I finally got my hands on Windows Server 2008 running IIS 7.0. Same problem; when POST request is chunked, the response times out. Perhaps I'm missing a setting that would enable the receipt of chunked incoming requests, but I have only read about settings that chunk the outgoing response. Previous Comments: [2012-03-27 13:34:28] a...@php.net @florian dot fernandez at navaho dot fr Looks like that. Could you try nginx+chunkin to confirm please? [2012-03-27 08:52:31] florian dot fernandez at navaho dot fr So, it is not a PHP problem ? [2012-03-23 15:27:44] clarkwise at gmail dot com Making the chunked request to a stock nginx 1.0.13 installation on Ubuntu yields a "411 Length Required" message, but enabling the ngx_chunkin module does indeed correctly serve the request and populate php://input and $HTTP_RAW_POST_DATA. This was done with both Ubuntu's distribution of PHP 5.3.6 and the php5.4-201203221530 snapshot. [2012-03-13 05:58:19] florian dot fernandez at navaho dot fr First of all, the problem is still here with PHP 5.4 and Apache 2.4.1, I previously made the mistake to precise the content-length in my headers. So here is what I found. If you send chunked http request but do not send the content-length (as we should do using HTTP 1.1 protocol) the body part of the request is empty (php://input returns nothing). This result remains valid for the following configuration where PHP runs via FastCGI : PHP 5.3.10 - APACHE 2.4.1 PHP 5.3-201203101230 - APACHE 2.4.1 PHP 5.4 - APACHE 2.4.1 PHP 5.4-201203101230 - APACHE 2.4.1 The same configuration with PHP running as mod_php is fine, the body request is available through php://input. [2012-03-09 09:48:29] paj...@php.net Try a snapshot please, 5.3.10 has nothing else but security fixes unrelated to this issue. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60826 -- Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
[PHP-BUG] Req #62913 [NEW]: add environment vars to proc_get_status()
From: clarkwise at gmail dot com Operating system: PHP version: Irrelevant Package: Program Execution Bug Type: Feature/Change Request Bug description:add environment vars to proc_get_status() Description: Would be useful to get an array of environment vars from the process. With proc_open(), a user-defined $env can be passed, but environment vars cannot be subsequently retrieved if the called command changes them. The most logical place seems to be returning an 'env' array among the other elements returned by proc_get_status(). -- Edit bug report at https://bugs.php.net/bug.php?id=62913&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62913&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62913&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62913&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62913&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62913&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62913&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62913&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62913&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62913&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62913&r=support Expected behavior: https://bugs.php.net/fix.php?id=62913&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62913&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62913&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62913&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62913&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62913&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62913&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62913&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62913&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62913&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62913&r=mysqlcfg
[PHP-BUG] Bug #53965 [NEW]: cannot find files w/ relative paths when loaded w/ "file://"
From:
Operating system: Windows XP
PHP version: 5.2.17
Package: XSLT related
Bug Type: Bug
Bug description: cannot find files w/ relative paths when loaded
w/ "file://"
Description:
I upgraded from PHP 5.2.5 (using binaries from windows.php.net), and now
the s 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
.
Warning: XSLTProcessor::importStylesheet(): I/O warning : failed to load
external entity "file%3A/C%3A/xsltest/include.xsl" in C:\xsltest\xsl.php on
line 11
Warning: XSLTProcessor::importStylesheet(): compilation error: file
file%3A//C%3A/xsltest/collection.xsl line 3 element include in
C:\xsltest\xsl.php on line 11
Warning: XSLTProcessor::importStylesheet(): xsl:include : unable to load
file%3A/C%3A/xsltest/include.xsl in C:\xsltest\xsl.php on line 11
Interestingly, in the first and third
errors, it is displaying the file:// protocol with only one slash
instead of the correct two.
IMPORTANT NOTE: This problem only occurs when the primary XSL document is
loaded with the "file://" protocol with one too few slashes. (See sample
PHP file.) Correctly, there should be three slashes when loading a local
file, where my existing code only has two (i.e., "file://C:/path"). Files
used to load, but now they don't. I don't see what changed in 5.2.9 to
cause that.
Ultimately, the question is why the main stylesheet loads but its
s do not, as they are in the same directory. Either they
should both load or neither should load.
---
Another thing I noticed is that the 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. See below:
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
=== versions differ 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
It might be a mere coincidence that in 5.2.9 both my code stopped working
and these versions differ, but it seemed worth noting.
Test script:
---
(based on XSL example at
http://us.php.net/manual/en/xsl.examples-collection.php)
C:\xsltest\xsl.php
=
load('collection.xml');
$xsl = new DOMDocument();
$xsl->load('file://C:/xsltest/collection.xsl'); // s fail
//$xsl->load('file:///C:/xsltest/collection.xsl'); // s work
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
=
C:\xsltest\collection.xsl
=
http://www.w3.org/1999/XSL/Transform";>
Hey! Welcome to 's sweet CD collection!
=
C:\xsltest\include.xsl
=
http://www.w3.org/1999/XSL/Transform";>
by -
=
C:\xsltest\collection.xml (same as on example page above)
=
Fight for your mind
Ben Harper
1995
Electric Ladyland
Jimi Hendrix
1997
Expected result:
include.xsl is loaded, and the script works, yielding:
Hey! Welcome to Nicolas Eliaszewicz's sweet CD collection!
Fight for your mindby Ben Harper - 1995
Electric Ladylandby Jimi Hendrix - 1997
Actual result:
--
include.xsl is not loaded (despite the fact that collection.xsl is loaded),
yielding these errors:
Warning: XSLTProcessor::importStylesheet(): I/O warning : failed to load
external entity "file%3A/C%3A/xsltest/include.xsl" in C:\xsltest\xsl.php on
line 11
Warning: XSLTProcessor::importStylesheet(): compilation error: file
file%3A//C%3A/xsltest/collection.xsl line 3 element include in
C:\xsltest\xsl.php on line 11
Warning: XSLTProcessor::importStylesheet(): xsl:include : unable to load
file%3A/C%3A/xsltest/include.xsl in C:\xsltest\xsl.php on line 11
--
Edit bug report at http://bugs.php.net/bug.php?id=53965&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53965&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53965&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53965&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53965&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53965&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53965&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53965&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53965&r=needscri
Bug #53965 [Com]: cannot find files w/ relative paths when loaded w/ "file://"
Edit report at http://bugs.php.net/bug.php?id=53965&edit=1
ID: 53965
Comment by: clarkwise at gmail dot com
Reported by:clarkwise at gmail dot com
Summary: cannot find files w/ relative paths
when loaded w/ "file://"
Status: Open
Type: Bug
Package:XSLT related
Operating System: Windows XP
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
Yes, the same thing happens for all currently available versions of PHP
5.3 (5.3.0 - 5.3.5).
As a note, libxslt is compiled against libxml 2.6.32 in all PHP 5.3.x
versions, while the bundled libxml is 2.7.x, as is the case with PHP
5.2.9 and greater.
Previous Comments:
[2011-02-15 14:47:11] cataphr...@php.net
PHP 5.2 is not supported anymore. Does this also affect PHP 5.3?
[2011-02-08 23:46:12] clarkwise at gmail dot com
Description:
I upgraded from PHP 5.2.5 (using binaries from windows.php.net), and now
the s 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 .
Warning: XSLTProcessor::importStylesheet(): I/O warning : failed to load
external entity "file%3A/C%3A/xsltest/include.xsl" in C:\xsltest\xsl.php
on line 11
Warning: XSLTProcessor::importStylesheet(): compilation error: file
file%3A//C%3A/xsltest/collection.xsl line 3 element include in
C:\xsltest\xsl.php on line 11
Warning: XSLTProcessor::importStylesheet(): xsl:include : unable to load
file%3A/C%3A/xsltest/include.xsl in C:\xsltest\xsl.php on line 11
Interestingly, in the first and third
errors, it is displaying the file:// protocol with only one slash
instead of the correct two.
IMPORTANT NOTE: This problem only occurs when the primary XSL document
is loaded with the "file://" protocol with one too few slashes. (See
sample PHP file.) Correctly, there should be three slashes when loading
a local file, where my existing code only has two (i.e.,
"file://C:/path"). Files used to load, but now they don't. I don't see
what changed in 5.2.9 to cause that.
Ultimately, the question is why the main stylesheet loads but its
s do not, as they are in the same directory. Either they
should both load or neither should load.
---
Another thing I noticed is that the 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. See below:
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
=== versions differ 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
It might be a mere coincidence that in 5.2.9 both my code stopped
working and these versions differ, but it seemed worth noting.
Test script:
---
(based on XSL example at
http://us.php.net/manual/en/xsl.examples-collection.php)
C:\xsltest\xsl.php
=
load('collection.xml');
$xsl = new DOMDocument();
$xsl->load('file://C:/xsltest/collection.xsl'); // s fail
//$xsl->load('file:///C:/xsltest/collection.xsl'); // s
work
$proc = new XSLTProcessor;
$proc->importStyleSheet($xsl);
echo $proc->transformToXML($xml);
=
C:\xsltest\collection.xsl
=
http://www.w3.org/1999/XSL/Transform";>
Hey! Welcome to 's sweet CD collection!
=
C:\xsltest\include.xsl
=
http://www.w3.org/1999/XSL/Transform";>
by -
=
C:\xsltest\collection.xml (same as on example page above)
=
Fight for your mind
Ben Harper
1995
Electric Ladyland
Jimi Hendrix
1997
Expected result:
include.xsl is loaded, and the script works, yielding:
Hey! Welcome to Nicolas Eliaszewicz's sweet CD collection!
Fight for your mindby Ben Harper - 1995
Electric Ladylandby Jimi Hendrix - 1997
Actual result:
--
include.xsl is not loaded (despite the fact that collection.xsl is
loaded), yielding these errors:
Warning: XSLTProcessor::importStylesheet(): I/O warning : failed to load
external entity "file%3A/C%3A/xsltest/include.xsl" in C:\xsltest\xsl.php
on line 11
Warning: XSLTProcessor::importStylesheet(): comp
