WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#41578 new enhancement

Assure that $_SERVER['PATH_INFO'] is available

Reported by: glehner Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.8.1
Component: Bootstrap/Load Keywords:
Focuses: Cc:

Description

I use the gatling web server on one of my servers (low ressorce consumption). gatling will not set the PATH_INFO environment variable if no path info is available which causes the home page of WP to enter an endless redirect loop.

I managed to fix this by setting $_SERVER['PATH_INFO'] to the empty string in an unhandled condition in wp-includes/load.php.

Attachments (1)

load.php.patch (794 bytes) - added by glehner 2 years ago.

Download all attachments as: .zip

Change History (5)

@glehner
2 years ago

#1 @SergeyBiryukov
2 years ago

  • Component changed from General to Bootstrap/Load

#2 follow-up: @ayeshrajans
2 years ago

Never heard of the Gatling server. It looks pretty cool!
I'm not sure if setting it to '' is the correct default value though. For examplewp-includes/rest-api/class-wp-rest-server.php:295 sets the default $_SERVER['PATH_INFO'] variable to /, which I believe is accurate.

By the way, Apache does not set this variable either, (neither in php-fpm /w mpm_event, nor in mod_php), and Wordpress runs just fine.

#3 in reply to: ↑ 2 @glehner
2 years ago

Replying to ayeshrajans:

Never heard of the Gatling server. It looks pretty cool!
I'm not sure if setting it to '' is the correct default value though. For examplewp-includes/rest-api/class-wp-rest-server.php:295 sets the default $_SERVER['PATH_INFO'] variable to /, which I believe is accurate.

That might be true. According to the CGI RFC the string '/' represents a single void path element. However I believe to have had problems with double '//' in redirected uris when setting PATH_INFO to '/'.

By the way, Apache does not set this variable either, (neither in php-fpm /w mpm_event, nor in mod_php), and Wordpress runs just fine.

Unless disabled by the AcceptPathInfo directive I am pretty sure that Apache sets PATH_INFO .

The problem here is that treatment of trailing '/' on uris might be different between Apache and gatling. Maybe Apache sanitizes redirects between https://example.org and https://example.org/ by itself while gatling does not and enters an infinite loop with the browser (Firefox in this case).


Having analized the code surrounding the "fix" it seams to me, that gatling is acting questionably at this point. There seems to be a shortcircuit between the directory index handling code and the generation of PATH_INFO leading to an extra PATH_INFO with value '/', which on the other hand seems not to contradict the RFC.

I think that Wordpress should be made immune against this anyway.

#4 in reply to: ↑ description @glehner
2 years ago

Replying to glehner:

I use the gatling web server on one of my servers (low ressorce consumption). gatling will not set the PATH_INFO environment variable if no path info is available which causes the home page of WP to enter an endless redirect loop.

I managed to fix this by setting $_SERVER['PATH_INFO'] to the empty string in an unhandled condition in wp-includes/load.php.


I have been able to run WordPress unmodified by adding the REQUEST_URI environment variable to the wrapper script which runs index.php as CGI or feeds it to FCGI respectively.

The gatling web server only provides the RFC3875 environment variables.

SCRIPT_NAME and PATH_INFO allow to assemble REQUEST_URI like this (Bourne shell):

REQUEST_URI="$SCRIPT_NAME"
if [ "$PATH_INFO" ]; then
    REQUEST_URI="${REQUEST_URI}/${PATH_INFO}"
fi
if [ "$QUERY_STRING" ]; then
    REQUEST_URI="${REQUEST_URI}?${QUERY_STRING}"
fi

Such a construction could be done by WordPress also, if REQUEST_URI is not available.

Note: See TracTickets for help on using tickets.