William A. Rowe, Jr. wrote:
> A number of CGI apps and apparently some IIS extensions do not properly
> seperate the headers from the response body with a cr-lf.
There have been a number of requests lately for proxy to "fix" bugs in
remote sites, or to accept chronically broken responses out there. Doing
this sits somewhere between "apache should be liberal in what it
accepts" and "we should not be breaking our server to fix someone else's".
The major difference between v1.3 and v2.0 of proxy was that as an
HTTP/1.0 proxy v1.3 simply transferred all broken requests warts and all
through itself, so many sites out there "just worked". Now, the proxy
feeds stuff through the filter stack, which requires at least a little
bit of protocol compliance.
I think the following policy should be followed with regard to HTTP
complicance:
- If proxy/ the filter stack decides to be liberal and accept some
broken protocol, a warning should be logged, and it should be clear in
the code that the behaviour is not standard.
- Proxy should not be accepting protocol violations that are not
accepted by Squid, etc.
> The following reply by a proxied http server works in apache 1.3, however,
> the 'outch' line is consumed by the header parser:
>
> <response>
> HTTP/1.1 200 OK
> Date: Sun, 18 Aug 2002 09:00:00 GMT
> Content-Type: text/plain
> Outch
>
> That Hurts!
> </response>
The behaviour in response to the above could be that the first line that
is not a header (ie a line with no : in it) could be treated as the
first line of the response.
The problem is that people have reported some other servers which have
broken the server version string into two lines - this is now
incompatible with the above kludge.
> ok, now what? In httpd 2.0.36 - .41-dev, we have an entirely different
> response due to the HTTP_HEADERS_IN filter, which looks more like,
>
> HTTP/1.1 502 BAD GATEWAY
My gut feel says that "bad gateway" is the correct reponse, because that
is exactly what the proxy is dealing with.
If this is correctly logged to the error log, an admin out there will be
able to see clearly that this is a remote site problem, and will not
think it is an apache bug.
> I suggest it isn't a nice surprise for HTTP/1.1 users.
>
> What are the effects of fixing this bug?
Important: this isn't a bug, but rather a request to bend the HTTP rules
for the benefit of some broken servers out there.
> 1. proxies can continue to forward responses from broken servers.
>
> 2. mod_cgi/cgid would handle broken responses from cgi apps, which
> forget to add the extra cr/lf pair after their headers.
>
> Are these effects desirable? I'm asking the list, but it would be nice if
> the 2.0 server reacts based on the principle of least astonishment.
I think the server should react with as much specific detail as is
possible. ie if the proxy rejects a remote site for any reason, it
should log why it did so in clear plain english so the admin is made
fully aware of what happened and why.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED]
"There's a moon
over Bourbon Street
tonight..."
