Re: Expect header 'understand' vs 'meet'

On Sep 8, 2011, at 4:43 AM, Amos Jeffries wrote:

> On 08/09/11 09:09, Roy T. Fielding wrote:
>> On Sep 7, 2011, at 1:24 PM, Julian Reschke wrote:
>> 
>>> On 2011-09-07 22:18, Jan Algermissen wrote:
>>>> ..
>>>>> No, that's unfortunately correct. Maybe we need to mention it.
>>>> 
>>>> Sorry to keep bugging - do you know the rationale behind this?
>>> 
>>> That predates my interest in HTTP.
>>> 
>>> Roy?
>> 
>> "Expect" is not part of my original design.  It is in the archives, somewhere.
>> 
>> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0263.html
>> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0296.html
>> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0316.html
>> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998MayAug/0165.html
>> 
>> IIRC, we had a discussion in the editorial group wherein I pointed
>> out that the MUST respond to 417 on extensions was a fatal flaw --
>> we might as well have made it non-extensible.
>> 
>> ....Roy
> 
> I don't think it is entirely fatal.
> 
> Expect: is cleanly restricted to probing features of the underlying pathway or requirements for success of the particular request+entity. Where things either work or fail hop-by-hop, no middle ground for almost worked, but room for middleware recovery.
> 
> Perhapse that usability scope needs to be re-worded and made clear.

Except for the minor detail that Expect was added after RFC2068, and hence
anyone implementing to the older RFC (or anyone just failing to implement
every single aspect of 2616) will not fail as defined.

> Here are some extensions where I believe using it could benefit HTTP implementations today:
> 
> 
> * testing for next-hop pipeline support
> 
> As I already suggested in the pipeline thread. Sending "Expect: pipeline" or similar would allow intermediaries pipeline support to be tested and alert them to the fact that extra efforts may need to be made to keep that connection alive.
> (I know the round-trip arguments, just pointing out it could be a useful extension of Expect: which is up to the client to decide whether to use or not.)

It is a performance extension.  We can't deploy a performance extension
using a field that drastically kills performance.

> * testing for working NTLM auth
> 
> Sending "Expect: connection-auth" during the auth logins over the Internet could be used by browsers to boost NTLM/Negotiate reliability. Intermediaries who cannot support or don't understand the requirements for NTLM can send 417 and break the potential infinite loop of auth, lost credentials, connection re-use mistakes, etc, etc.
> Yes the intermediaries can (and do) today detect the auth headers going through. This still breaks when transiting the intermediaries which lack proper support.

True.  OTOH, such a client would break on every working install
of NTLM as well, which means it can't ever be deployed because
the main reason to use NTLM is to support intranet services.

> * testing for secure communications
> 
> Sending "Expect: tls" during a request to indicate that it must only transit over encrypted connections. Intermediaries who don't comply or understand, send 417 and the connection fails to safety.

The client already controls whether or not it uses TLS.
Expect cannot be used to force an intermediary to do something
on the next hop, since the client can't trust the intermediary
to respect Expect.

> I'm sure thats not the end of the possibilities. But it goes to show that Expect: is useful in its current form because of the MUST.

I don't think so.  Even the 100-continue support would have failed
if Apache hadn't deployed it early.  Expect is only useful for that
and for private extensions within corporate networks where one can
ensure that all of the internal servers support Expect in the same
way.

....Roy

Received on Thursday, 8 September 2011 18:02:01 UTC