Re: #468 p2: Expectation extensions

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.

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

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
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.

....Roy

Received on Thursday, 12 September 2013 18:50:30 UTC