W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Expect header 'understand' vs 'meet'

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 08 Sep 2011 23:43:53 +1200
Message-ID: <4E68AA79.6060604@treenet.co.nz>
To: ietf-http-wg@w3.org
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.

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

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

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

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.

Received on Thursday, 8 September 2011 11:44:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC