Re: #458: Requirements upon proxies for Expect

[Amos Jeffries <[e-mail]>]

On 4/06/2013 5:12 p.m., Willy Tarreau wrote:
> 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 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