Re: #468 p2: Expectation extensions

On 2013-09-12 04:17, Mark Nottingham wrote:
>
> 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).
> ...

I remain unconvinced.

I just tried "expect: foobar" with a set of sites I use, and many of 
them (facebook.com, twitter.com, google.com, spiegel.de...) indeed 
return 417 although they do not appear to run apache (it's not always 
easy to tell).

My preference would be leave things as they are, add a warning about 
incomplete support, and file issues against the servers that are known 
to be broken.

Best regards, Julian

Received on Thursday, 12 September 2013 07:47:23 UTC