Re: #468 p2: Expectation extensions

On 2013-09-12 09:46, Julian Reschke wrote:
> 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).

(google.com does not, sorry for the inaccuracy).

> ...

Best regards, Julian

Received on Thursday, 12 September 2013 08:37:05 UTC