REQUEST_URI fix for IIS misses certain configurations

Patch against trunk (rev. 6201) to resolve this issue.

(In [6203]) Check for ORIG_PATH_INFO on IIS. props brh, fixes #5160

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

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.

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/

At http://brh.numbera.com/blog/index.php

PATH_INFO: ORIG_PATH_INFO: /blog/index.php SCRIPT_NAME: /blog/index.php

At http://brh.numbera.com/blog/index.php/2007/09/09/new-version-of-the-popupnotify-windows-forms-control/

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

Dang, there should be some newlines there, but you get the picture.

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.

(In [6208]) IIS REQUEST_URI-setting fixes from snakefoot. fixes #5160 for trunk

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.

Snakefoot's patch works for me.

[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.

tellyworth,

Have you seen this Undefined Index notice or is this just hypothetical?

2.3.1 has been released moving to 2.3.2

Patch for trunk (Updated with check if PATH_INFO is empty)

Patch for branch 2.3 (Updated with check if PATH_INFO is empty)

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'];?>&amp;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 :)

People with 2.5 are reporting the undefined index errors on IIS from this patch:

See: http://wordpress.org/support/topic/164618

(In [7757]) Check if PATH_INFO is set to avoid undefined index errors. see #5160

(In [7758]) Check if PATH_INFO is set to avoid undefined index errors. see #5160

Milestone 2.5.2 deleted