Re: #458: Requirements upon proxies for Expect

On Tue, Jun 04, 2013 at 11:37:14AM +1000, Mark Nottingham wrote:
> So, you'd like to relax this requirement for all connections, not just when
> the proxy knows that the forward hop is 1.0?

Yes, for three reasons :
  - it's the only way for a content analyser (think anti-virus) to get
    the payload ;
  - clients already expect to receive multiple non-final 100 responses
  - we never know for sure the version of the next hop, and deciding a
    behaviour rule this way could probably introduce more confusion than
    having a general one

> I think that's sensible, but it's a bigger change; what do others think? 

(...)
> >> I'd also really like to see us define what "final status code" means; is it
> >> just 417? Any 4xx or 5xx status? Any non-1xx status?
> > 
> > I think that since only 1xx are non-final, final are all other ones, but
> > you're right, we should define this term.
> 
> Anyone disagree with "final" being any non-1xx status code? Note that this
> would allow an origin to respond with 200 OK to a request with an expectation
> in it (when the entire request hasn't yet been received). I think that's OK,
> just wanted to point it out.

Anyway, this is already allowed in some form since we ask the clients to
forward the body is they get no response for a certain amount of time. So
that means that over the wire we can see a final response without a 100/417.
And the most common examples of such final responses I can have that will
not even wait for the body are 401 and 302. The purpose of Expect precisely
is to let the server decide without passing it the payload. If we prevent
the server from asking for authentication without getting the payload, I
think that the usefulness of Expect becomes quite limited.

Best regards,
Willy

Received on Tuesday, 4 June 2013 05:13:24 UTC