- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Sat, 10 Aug 2013 09:00:12 +0000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- cc: IETF HTTP WG <ietf-http-wg@w3.org>
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.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Saturday, 10 August 2013 09:00:35 UTC