[wp-trac] [WordPress Trac] #41578: Assure that $_SERVER['PATH_INFO'] is available

[WordPress Trac]

#41578: Assure that $_SERVER['PATH_INFO'] is available
----------------------------+------------------------------
 Reporter:  glehner         |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Bootstrap/Load  |     Version:  4.8.1
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by glehner):

 Replying to [comment:2 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 example`wp-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
 [https://tools.ietf.org/html/rfc3875#section-4.1.5 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/41578#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform