Re: #468 p2: Expectation extensions (was: Expect header 'understand' vs 'meet')

On 10/08/2013, at 6:40 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> I spent a few days trying to wrangle the issues around the
> Expect header field in p2 (#466, #467, #458, #468) and have
> run into a brick wall.  I think we should reopen #468,
> remove everything except 100-continue, and then specify the
> 100-continue mechanism as it is implemented in practice.
> 
> I tried to rewrite the section so that the existing text
> would make sense as a must-understand-or-fail feature for
> HTTP/1.1.  I was able to do that, based on the fantasy that
> HTTP/1.1 servers had at least deployed that much.  Apparently,
> I had already forgotten the testing I did two years ago, and
> nothing has changed since then.
> 
> In short, Apache httpd is the only server that I could find
> which sent 417 Expectation Failed in response to an expectation
> extension.  Apache does not actually parse the syntax -- it
> simply rejects anything that isn't 100-continue.  There exists
> a patched version of nginx that does the same, but only for
> file upload requests that are about to succeed.  IIS does not
> appear to support Expect at all, though it may for some resources
> that I could not find.
> 
> Then, I stopped writing, since there is no point in
> specifying a must-understand feature that still hasn't been
> implemented consistently 16 years after it was originally defined.
> 
> What we can do is define how "Expect: 100-continue" is implemented
> in practice as an indication that the client will wait some
> implementation-dependent amount of time to see if it gets an
> error before continuing to send the request body.  We can specify
> that sensibly, including its shortcomings, if we discard the
> must-understand semantics and the protocol versioning bit
> about responding with 417 if the next hop is HTTP/1.0.
> 
> I know that #468 was closed due to lack of interest, but the
> alternative is to specify something that hasn't been implemented
> and will never be interoperable outside a closed environment
> (where both client and server are controlled by the same org),
> and we don't need Expect extensions in a closed environment.

Based on discussion so far, that seems like a reasonable path forward. Personally, I'm +1 on this (as should have been clear by all of the Expect-related issues I raised).

Roy, are you taking a stab at this?


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

Received on Thursday, 12 September 2013 02:18:19 UTC