httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: svn commit: r1357986 - /httpd/mod_fcgid/trunk/modules/fcgid/fcgid_bridge.c
Date Thu, 03 Oct 2013 04:58:24 GMT
Jeff Trawick wrote:

>     URL:
>     <>
>     Log:
>     Avoid internal sub-requests and processing of Location headers when
>     in FCGI_AUTHORIZER mode, as the mod_fcgid_authenticator(), etc. hook
>     functions report an error if the script returned a Location header and
>     redirections are nonsensical in this mode.
>     Previously, the handle_request_ipc() and handle_request() functions
>     would
>     examine this header when in FCGI_AUTHORIZER mode and then possibly
>     execute
>     an internal sub-request, which has no particular use, as its return
>     value
>     is ignored and its output may conflict with that of the actual content
>     generation phase.
>  From the FastCGI spec (6.3):
> "For Authorizer response status values other than "200" (OK), the Web 
> server denies access and sends the response status, headers, and content 
> back to the HTTP client."
> I was initially confused when looking at this commit (nothing like 
> reviewing one year later) wondering if it broke this requirement, but 
> AFAICT 2.3.7 didn't support the feature anyway, so no regression.  (Some 
> iff statements in this code are what control it.)

   Yes, I believe that's correct (it's been a while).  It's a really
good question and worth having a second pair of eyes.

   I did a smidge of testing today, comparing 2.3.7 and trunk,
with a test Authorizer that returns things like 403, 500, etc.
I believe there's no difference for most of these cases; the 2.3.7
behaviour is to return a 401, which is still the case.  (This may
not follow the spec, as you point out, but is the existing behaviour;
I'll double-check on that tomorrow.)

   The intent of r1357986 was to deal with a particular, wonky
sub-case, when the Authorizer returns 200 (so the spec paragraph
doesn't apply in this case, as it's a 200 OK response), but adds
a Location header with a relative (not absolute) path.  In this case,
2.3.7 and previous will run the sub-request and return whatever comes
out of that -- sometimes munging the end result as a consequence.
(Note that a 200 with an absolute URL in a Location header just produces
a 401 response.)

   For example, if the Authorizer returns "Location: /cgi-bin/printenv"
and a 200, you get something strange like:

HTTP/1.1 200 OK

SERVER_SOFTWARE="Apache/2.5.0-dev (Unix) mod_fcgid/2.3.7"
<title>200 Unknown Reason</title>
<h1>Unknown Reason</h1>

   Or if the Location is bad (say, "Location: /cgi-bin/printenv.FOO")
then you get a 404 with a "200 Unknown Reason" glued on:

HTTP/1.1 404 Not Found

<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL /cgi-bin/printenv.FOO was not found on this server.</p>
<title>200 Unknown Reason</title>

   So r1357986 is just trying to handle those 200 OK + "Location: /..."
header cases.  If it does more than that, we should review further,
but that was the only intent ... IIRC after about a year or so.


GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820  6715 F54F E648 0883 35A9

View raw message