Jeff Trawick wrote:
URL: http://svn.apache.org/viewvc?rev=1357986&view=rev
<http://svn.apache.org/viewvc?rev=1357986&view=rev>
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
...
CONTEXT_PREFIX="/cgi-bin/"
...
SERVER_SOFTWARE="Apache/2.5.0-dev (Unix) mod_fcgid/2.3.7"
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>200 Unknown Reason</title>
</head><body>
<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
...
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /cgi-bin/printenv.FOO was not found on this server.</p>
</body></html>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>200 Unknown Reason</title>
</head><body>
====================================
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.
Chris.
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
