Re: Deploying new expectation-extensions

Actually the concept goes back to Thomas Moore :)

The Expects header breaks the universal law that silence does not mean 
assent.  Instead it requires recipients to know that they need to 
actively deny a capability (else the sender will assume the capability 
is there).  Any recipient unaware of the Expects header requirements 
will ignore it, which is a failure condition.  So this creates all sorts 
of issues around sending Expects headers to HTTP/1.0 servers or 
intermediaries, or non-compliant (in terms of requirements to bounce) 
servers/intermediaries. 

The goal of the Expects header I believe has been captured in the spec, 
whether that goal was worthy or not is another matter.  I think mostly 
confusion arises because it's not clear in the spec that the Expects 
header is intended to be used where a required extension capability 
would NOT normally work (or degrade gracefully) through any agent that 
was not explicitly aware of it. 

This covers 2 cases that I can see:

1: where the extension was semantically incompatible with the current 
version of HTTP. 
2: where the extension was optional in the current version but for some 
reason indispensable to the client.

AFAIK the only instance referred to in the spec (100-Continue) is an 
instance of 2, but not particularly useful since it's easier for an 
agent to cope with lack of 100-continue than it is to cope with being 
disconnected with a 417.  There aren't really that many optional bits of 
HTTP/1.1 that a client could reasonably decide were indispensible, 
especially considering the prospects of daring to use an Expects header.

Version changes I think is a better way to cope with the first class of 
use-cases.  There's no difference between a chain of 
agent->intermediary->server supporting a newer version number than 
supporting an extension.  It's just a matter of labelling.

Adrien




Roy T. Fielding wrote:
>
> On Apr 3, 2008, at 8:08 PM, Mark Baker wrote:
>> On Thu, Apr 3, 2008 at 10:56 PM, Adrien de Croy <adrien@qbik.com> wrote:
>>>  However relying on non-compliance of proxies in this case would be
>>> foolhardy.  Changing the semantics of Expects I don't think is that 
>>> great an
>>> option either (actually I'd vote to deprecate it along with 305 Use 
>>> Proxy)
>>
>> +1
>
> That train has long since left the station.
>
>  http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998MayAug/0165.html 
>
>  http://lists.w3.org/Archives/Public/ietf-http-wg-old/1998MayAug/0192.html 
>
>
> Version numbers in protocols are a good thing.  Stupid IETF politics
> and FUD regarding the so called "risk" of changing the version number
> (when an incompatible change is made to the protocol) are the only
> reasons they don't work, and every time they end up biting us.
>
> ....Roy
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Friday, 4 April 2008 05:53:35 UTC