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: 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>
Message-ID: <83134.1376125212@critter.freebsd.dk>
In message <D0C5E9DA-2332-4505-9395-2D9988B3FF48@gbiv.com>, "Roy T. Fielding" w

>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")) {
                        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

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