httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Proxy: Handling Interim Responses
Date Tue, 02 Oct 2007 10:04:11 GMT
On Tue, Oct 02, 2007 at 01:12:08AM +0100, Nick Kew wrote:
> RFC2616 mandates that a proxy MUST return interim (1xx)
> responses to an HTTP/1.1 client, except where the proxy
> itself requested the interim response.  I'd interpret
> that slightly liberally, to mean we MUST return an interim
> response if the Client has asked for one.

Why the "interpretation"?  It's a MUST not a SHOULD.

> Our proxy currently eats all 1xx responses.  That's broken.
> It could possibly have some bearing on that elusive PR 37770.
> 
> As I see it:
>   (1) 100-Continue should be forwarded to the client if there's
>       an Expect header asking for it.  If there isn't, then
>       it really doesn't matter.

Again, it's a MUST where the client supports HTTP/1.1.  The proxy cannot 
know whether or not it "matters"; e.g. the 100 can prevent client I/O 
timeouts if response generation may take a long time.

>   (2) 101 Switching Protocols needs a framework to plug in a
>       provider for switched protocols.  In the absence of one,
>       we should instead return 502.  However, since we strip
>       out any Upgrade request header, the question is only
>       one of error-correction, and current behaviour is
>       probably no worse.

A 502 seems reasonable here.

>   (3) Any other 1xx is unrecognised, and it's not clear
>       to me whether it's best to return 502 or to forward
>       the interim response.

Again, MUST forward.

joe

Mime
View raw message