Subject: Re: #458: Requirements upon proxies for Expect

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Jun 2013 11:37:14 +1000

On 31/05/2013, at 4:13 PM, Willy Tarreau <[email-masked]> wrote:

>> OK. How do other folks feel about this? I think the proposal is to change:
>> 
>>> If the proxy knows that the version of the next-hop server is HTTP/1.0 or
>>> lower, it must not forward the request, and it must respond with a 417
>>> (Expectation Failed) status code.
>> 
>> to:
>> 
>> """
>> If the proxy knows that the version of the next-hop server is HTTP/1.0 or
>> lower, it MAY either respond with a 417 (Expectation Failed) without
>> forwarding the request, or with a 100 (Continue) status code while forwarding
>> it.
>> """
> 
> I think it's better, but still I don't see the issue which could be caused
> by a proxy returning 100 when the server is known to be 1.1. I tend to
> consider that expect:100 is more related to the connection than to the
> whole path, eventhough it's still not hop-by-hop in its definition. After
> all, the first goal is to avoid uselessly sending huge amounts of data.
> And the fact that we define the behaviour of each element in the chain
> for this expect and 100 tends to confirm this hop-by-hop behaviour.

So, you'd like to relax this requirement for all connections, not just when the proxy knows that the forward hop is 1.0?

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

>> Note that this is applying to proxies, NOT gateways (like haproxy), which
>> AFAICT don't have any requirements applying to them. Hmm.
> 
> I understand, but some proxies will analyse posted contents to detect
> malware activity or information leaks etc... and will have to send 100
> themselves anyway.

Yep.

>> 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.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 4 Jun 2013 07:12:59 +0200

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? 

(...)
> 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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 05 Jun 2013 15:59:08 +1200

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

I agree it is sensible for any recipient to be able to 100 or 417 the 
request. But we should however highlight that 100 means some (possibly 
very large) payload will be transferred, and that sending the payload 
may result in extreme bandwidth waste and may be at odds with the 
client-origin webapps intention for it. ie discourage but permit.

The example case here is; the server may only be sending 100-continue to 
POST if a certain content-encoding or extension header is present. Think 
about a certain unnamed video uploader which requires "X-Account: 
<secure hash>" and responds 200 immediately with a form-based login page 
if the credentials are absent.

For that matter, there is no explicit restriction on which party in the 
chain can add Expect: is there? so there is a potential case for Expect: 
being sent and responded by two hops in the middle of a chain.

Amos