W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 10 Aug 2013 11:28:04 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, IETF HTTP WG <ietf-http-wg@w3.org>
Message-ID: <20130810092804.GO4079@1wt.eu>
On Sat, Aug 10, 2013 at 09:00:12AM +0000, Poul-Henning Kamp wrote:
> In message <D0C5E9DA-2332-4505-9395-2D9988B3FF48@gbiv.com>, "Roy T. Fielding" w
> rites:
> 
> >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.
> 
> Same for Varnish:
> 
>         /* XXX: Expect headers are a mess */
>         if (req->err_code == 0 && http_GetHdr(req->http, H_Expect, &p)) {
>                 if (strcasecmp(p, "100-continue")) {
>                         wrk->stats.client_req_417++;
>                         req->err_code = 417;
> 		} [...]
> 
> >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.
> 
> Expect ran foul of Gettys 3rd rule from the start:
> 
> 	The only thing worse than generalizing from one example is
> 	generalizing from no example at all.
> 
> It was neither needed nor useful, and should never have been added.
> 
> There's a lesson HTTP/2.0 could have learned, but we clearly don't
> have time for that.
> 
> >What we can do is define how "Expect: 100-continue" is implemented [...]
> 
> I think we should deprecate Expect.
> 
> Document the 100 and 417 responses for back- & bug-wards compatibility
> and write that clients SHOULD NOT send Expect.

I disagree with deprecating it, it's the only way to send non-idempotent
request over a reused connection. However I agree that it's non-sense to
try to make it handle everything that can happen in the world. The use
case was only to get the server's ACK for sending data and nothing else,
so let's simplify it to only match the original intent (which is the only
one in use) and forget every useless overdesign that might have been
thought about.

Willy
Received on Saturday, 10 August 2013 09:28:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC