Bug 68125 - PATH_INFO corruption
Summary: PATH_INFO corruption
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: httpd   
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-06 18:41 UTC by ellson
Modified: 2007-04-18 16:43 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-19 08:06:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description ellson 2002-07-06 18:41:16 UTC
Description of Problem:
Unable to pass through PATH_INFO that look like URLs.
This may be a new security feature?  If so, is there a way to disable?

Version-Release number of selected component (if applicable):

How Reproducible:

Steps to Reproduce:
1. Install test script "pathinfo" in  /var/www/cgi-bin/  and make executable

    puts "Content-type: text/plain\n"
    if {[info exists env(PATH_INFO)]} {puts PATH_INFO=$env(PATH_INFO)}

2. Try:   http://localhost/cgi-bin/pathinfo/http://localhost/
3. Try:   http://localhost/cgi-bin/pathinfo/http%3A%2F%2Flocalhost/ 

Actual Results:
2. pathinfo prints: /http:/localhost/     i.e. one "/" is missing
3. doesn't even get to pathinfo.  Server returns Object Not Found.

Expected Results:
PATH_INFO should contain exact string passed to server.

Additional Information:

Comment 1 Joe Orton 2002-07-08 08:08:38 UTC
Hi, use of PATH_INFO must be explicitly configured now in 2.0 (I recommend
reading the migration guide at /usr/share/doc/httpd-2.0.36/migration.html).

Comment 2 Joe Orton 2002-07-08 08:09:59 UTC
Please excuse and ignore previous comment: I reproduced this problem after
adding the comment, and am investigating further, I only meant to change the

Comment 3 ellson 2002-07-23 19:55:33 UTC
Related to this bug, the contents of PATH_TRANSLATED and SCRIPT_NAME are also
totally broken.

Using /cgi-bin/cgienv containing:
  puts "Content-type: text/plain\n"
  foreach var [lsort [array names env]] {puts "$var = $env($var)"}

Testing with:

Results in:
  PATH_INFO = /http:/test.com/
  PATH_TRANSLATED = /var/www/html/http:/test.com/
  SCRIPT_NAME = /cgi-bin/cgienv/http:

Comment 4 Joe Orton 2002-07-24 13:39:50 UTC
Other than the fact that "//" has been normalised into "/", the PATH_TRANSLATED
and PATH_INFO appear correct.  The PATH_INFO is defined for passing a URI path
segment, whereas you are trying to use a complete absoluteURI: if you want to
the value to be passed through intact, maybe the only correct way to do it is to
use a query string.

The old behaviour would appear to be incorrect according to the CGI specification
http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html, where the grammar
for PATH_INFO does not allow a double-slash.

A URI path containing %2F is explicitly rejected with a 404 by Apache for
security reasons (%2F is allowed in a query string, however); this behaviour has
been present since Apache 1.2.

The SCRIPT_NAME problem appears to be a valid bug though.

Comment 5 Joe Orton 2002-07-24 13:42:19 UTC
The Apache bug tracking the SCRIPT_NAME issue is here:


Comment 6 ellson 2002-07-24 14:09:47 UTC
The old PATH_INFO behaviour is not incorrect according to

The PATH_INFO syntax spec is:

    PATH_INFO = "" | ( "/" path )
    path      = segment *( "/" segment )
    segment   = *pchar
    pchar     = <any CHAR except "/">
Note that segment can be a null string because *pchar
specifies zero or more characters:

        A rule preceded by an asterisk ("*") may have zero or more
        occurrences. A rule preceded by an integer followed by an asterisk
        must occur at least the specified number of times.

Comment 7 Joe Orton 2003-06-19 08:06:20 UTC
Upstream are tracking the double-slashes vs PATH_INFO issue at:


Note You need to log in before you can comment on or make changes to this bug.