Opened 17 years ago
Closed 17 years ago
#4853 closed defect (bug) (fixed)
Changeset 5889 broke my blog
Reported by: | Nazgul | Owned by: | |
---|---|---|---|
Milestone: | 2.3 | Priority: | high |
Severity: | critical | Version: | 2.3 |
Component: | General | Keywords: | has-patch |
Focuses: | Cc: |
Description
The IIS changes made in changeset [5889] broke my IIS test-blog.
If I dump $_SERVER['REQUEST_URI']
after that piece of code it returns /blogsvn/index.php/blogsvn/index.php instead of the expected /blogsvn/index.php.
It appears that on line 44 both $_SERVER['SCRIPT_NAME']
and $_SERVER['PATH_INFO']
contain /blogsvn/index.php.
ENV: PHP 4.4.5 on IIS, running r5966
Attachments (3)
Change History (12)
#2
@
17 years ago
Can you provide us with more data points?
For example, with PATHINFO permalinks on, what are REQUEST_URI, SCRIPT_NAME, and PATH_INFO?
#3
@
17 years ago
Let me try that again:
For example, with PATHINFO permalinks on, what are REQUEST_URI, SCRIPT_NAME, and PATH_INFO on an is_single() URL?
#4
@
17 years ago
I'm running Wordpress on IIS and had the same problem as these people, where WP-Cache wouldn't work because the REQUEST_URI generated by IIS + PHP was missing PATHINFO:
http://www.cpuidle.de/blog/?p=30
Without PATHINFO then it was only script name without the actual post-path:
*/blog/index.php*/my-post/
Guess one should change it so if the PATH_INFO is the same as SCRIPT_NAME, then ignore PATH_INFO.
#5
@
17 years ago
Still need to know what SCRIPT_NAME and PATH_INFO look like on an is_single() URL. They might not be the same there -- and then the comparison wouldn't be true.
#6
@
17 years ago
Both $_SERVER['SCRIPT_NAME']
and $_SERVER['PATH_INFO']
contain the same on an is_single() URL, while $_SERVER['REQUEST_URI']
is unset before the IIS fix code an contains those two concatenated afterwards.
For example:
$_SERVER['SCRIPT_NAME']: /blogSVN/index.php/2007/07/11/gcrqzk
$_SERVER['PATH_INFO']: /blogSVN/index.php/2007/07/11/gcrqzk
$_SERVER['REQUEST_URI']: /blogSVN/index.php/2007/07/11/gcrqzk//blogSVN/index.php/2007/07/11/gcrqzk/
Attached patch fixed it for me, but could use some testing (preferably also by other IIS users)