Assure that $_SERVER['PATH_INFO'] is available

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

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

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.

[glehner]

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.

[glehner]

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.

[jorbin]

While using uncommon webservers should be supported in the sense that WordPress should make efforts to function in them, I think it falls under the ​Clean, Lean, and Mean philosophy to say that in these instances it is ok for people to modify wrapper scripts or add something to wp-config.php to work rather than changing WordPress for every other site.

As this is the only reference to gatling in all of trac and there has been no progress for seven years, I am closing this as wontfix. Discussion can continue (or rather, restart) and this ticket can be reopened if situations change.