#5160 closed defect (bug) (fixed)
REQUEST_URI fix for IIS misses certain configurations
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 2.6 | Priority: | normal |
Severity: | normal | Version: | 2.5 |
Component: | General | Keywords: | REQUEST_URI has-patch needs-testing |
Focuses: | Cc: |
Description
The host I use (on IIS6) stores what would normally be in "PATH_INFO" in "ORIG_PATH_INFO". This confuses Wordpress' fixes in wp-settings.php, leading to a REQUEST_URI that is missing the page name. For example:
If I'm on: http://brh.numbera.com/blog/wp-admin/edit.php?paged=2
It would produce: http://brh.numbera.com/blog/wp-admin/?paged=2
Attachments (3)
Change History (28)
#2
@
17 years ago
- Keywords has-patch needs-testing added; has_patch needs_testing removed
- Milestone set to 2.4
#4
@
17 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Think the proper solution is to remove the "If root then simulate that no script-name was specified". It only works for the index.php and fails when running around in the admin-panel.
-Rolf
#6
@
17 years ago
- Milestone changed from 2.3.1 to 2.4
Snakefoot, but that reverts the ORIG_PATH_INFO change.
Perhaps we should check ORIG_PATH_INFO earlier and set PATH_INFO from it. That way we can just use PATH_INFO from then on.
#7
@
17 years ago
The problem is that REQUEST_URI is missing the page name, while rest of the path is correct (Everything comes from SCRIPT_NAME). The patches I have attached fixes the problem with the missing page-name, by not removing it from SCRIPT_NAME (bug introduced by me).
The bug introduced by me breaks the admin-panel, and should be fixed on trunk and branch right away.
If we should handle the situation of ORIG_PATH_INFO being set and no PATH_INFO, then we need to know the values of PATH_INFO, ORIG_PATH_INFO, SCRIPT_NAME in these two situations:
http://brh.numbera.com/blog/index.php
http://brh.numbera.com/blog/index.php/my-post-name/
#8
@
17 years ago
At http://brh.numbera.com/blog/index.php
PATH_INFO:
ORIG_PATH_INFO: /blog/index.php
SCRIPT_NAME: /blog/index.php
PATH_INFO: /2007/09/09/new-version-of-the-popupnotify-windows-forms-control/
ORIG_PATH_INFO: /blog/index.php/2007/09/09/new-version-of-the-popupnotify-windows-forms-control/
SCRIPT_NAME: /blog/index.php
#10
@
17 years ago
The combination of just SCRIPT_NAME + PATH_INFO seems to cover your configuration, without needing the ORIG_PATH_INFO as PATH_INFO is being set.
Not sure if all PHP + CGI configurations configures the ORIG_PATH_INFO as being the combination of SCRIPT_NAME + PATH_INFO. But if they did, then the patch to handle the situation of no PATH_INFO would look something like this:
if (isset(ORIG_PATH_INFO) && empty(PATH_INFO) && SCRIPT_NAME!=ORIG_PATH_INFO) REQUEST_URI = ORIG_PATH_INFO; else if (SCRIPT_NAME==PATH_INFO) REQUEST_URI = SCRIPT_NAME; else REQUEST_URI = SCRIPT_NAME . PATH_INFO; REQUEST_URI .= QUERY_INFO
Not sure it is a good idea to try fix a bug which cannot be tested if fixed. The two patches I have attached for trunk and branch will solve the problem for brh.
#12
follow-up:
↓ 13
@
17 years ago
- Milestone changed from 2.4 to 2.3.1
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening for 2.3.1 consideration. brh, can you let me know if that changeset fixes the issue for you? Feedback from people with other IIS configurations would also be appreciated.
#14
@
17 years ago
[6208] removed an empty() check in the older code, allowing an Undefined Index notice if $_SERVERPATH_INFO? is not set. Not sure if that warrants a new ticket.
#15
@
17 years ago
tellyworth,
Have you seen this Undefined Index notice or is this just hypothetical?
#17
@
17 years ago
- Cc cimmino.marco@… added
A person emailed me that have a bug with my plug-in (Cimy Swift SMTP) and IIS, so I gave him the patched wp-settings.php and all went ok.
The code not working under IIS was:
<form method="post" action="<?php echo $_SERVER['REQUEST_URI'];?>&updated=true">
but also this piece of code that I gave to him to fix the problem wasn't ok before and it's ok after the patched wp-settings.php:
<form method="post" action="<?php echo add_query_arg('updated', 'true', wp_get_original_referer()); ?>">
so my 2 cents for this fix :)
Patch against trunk (rev. 6201) to resolve this issue.