---- test.html ---- <!--#echo var="PATH_INFO" --> <!--#echo var="QUERY_STRING" --> ------------------- ---- test2.html ----- <!--#include virtual="test.html/path?query" --> --------------------- Requesting http://site/test.html/path?query gives me: path query Requesting http://site/test2.html gives me: (none) query They should match. From investigation, I think it's because the PATH_INFO isn't setup in the environment of the subrequest. Digging around in src/modules/standard/mod_include.c - around line 2181 QUERY_STRING is fixed up, however PATH_INFO isn't. If I add this in: if (r->path_info) { ap_table_setn(r->subprocess_env, "PATH_INFO", r->path_info); } Then it seems to then work fine for my simple test case.
I could imagine, that this is intentional. Anyway, changing that would break backwards compat, so wontfix.
Why would fixing the bug break backwards compatibility? If you want to check for PATH_INFO, or the value of the PATH_INFO then it doesn't work. If you want to check for a lack of PATH_INFO it doesn't work. Anybody who is currently trying to check PATH_INFO within a sub-include will not be getting proper results - therefore they cannot be depending on this result. My diagnosis and/or fix of the problem may be wrong - but the bug is fixable.
You should get the PATH_INFO of the caller. That behaviour won't be changed. If you think, another behaviour is betterm just make a featrue request for 2.1.
The PATH_INFO of the caller is a different value and may not even exist. Did you even bother *reading* my bug report and looking at the test case?
Sure. echoing a NULL pointer gives (none).