Re: #468 p2: Expectation extensions

On 2013-09-12 20:36, Roy T. Fielding wrote:
> On Sep 12, 2013, at 10:46 AM, Julian Reschke wrote:
>
>> On 2013-09-12 18:58, Roy T. Fielding wrote:
>>> On Sep 12, 2013, at 12:46 AM, Julian Reschke wrote:
>>>> 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).
>>>
>>> They all run Apache code -- they just tweaked it a bit (or a lot).
>>
>> spiegel.de claims to use something squid-ish.
>
> Must be a recent version.

http://redbot.org/?uri=http%3A%2F%2Fspiegel.de&req_hdr=expect%3Afoobar

says "3.1.4".

> www.akamai.com fails on curl with a 403 (apparently attempting
> to redirect it to an internal server with access control).

Indeed: 
http://redbot.org/?uri=http%3A%2F%2Fwww.akamai.com&req_hdr=expect%3Afoobar

> http://s.a.ak6i.net/a1/ ignores Expect even though it claims
> to be Apache (it is probably Zeus)
>
> http://statse.webtrendslive.com/dcsd5z3icpifwzr6ntaprqwib_7q9t/dcs.gif
> ignores Expect (MS IIS/6.0)
>
> http://www.google-analytics.com/__utm.gif?
> ignores Expect (Golfe2)
>
> http://api.demandbase.com/api/v2/ip.json
> handles Expect correctly and doesn't look like Apache:
>
>     HTTP/1.1 417 EXPECTATION_FAILED
>     Content-Length: 0
>     Connection: Close
>
> http://adobe.tt.omtrdc.net/m2/adobe/mbox/standard
> ignores Expect (Adobe Target, probably nginx-based)
>
> http://p.typekit.net/p.gif
> handles Expect correctly (ECSF, probably Apache-based)
>
> https://1295336.fls.doubleclick.net/activityi
> ignores Expect (Floodlight server)
>
> Note that the examples above are analytics and CDNs, which means
> extensively referred to by most commercial sites.
>
> My suggestion is that we remove the extension syntax and leave a
> requirement that anything other than "100-continue" SHOULD be

But the servers that ignore Expect today will continue to be broken, right?

> given a response of 417 unless it indicates a private extension
> recognized and implemented by the recipient.  The extension syntax
> is problematic because it doesn't look at all like 100-continue
> and implies that extensions will actually work.  They won't.
> ...

What part of the syntax are you referring to? Anything beyond "expect-name"?

Best regards, Julian

Received on Thursday, 12 September 2013 19:26:23 UTC