- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 02 Jul 2014 09:56:24 +0000
- To: "Eric J. Bowman" <eric@bisonsystems.net>
- cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In message <20140702034611.2dd18217cd132f02ab3bf24f@bisonsystems.net>, "Eric J. Bowman" writes: >"Poul-Henning Kamp" wrote: >> >> >Hm? That would imply buffering all responses before displaying them? >> >> Exactly... :status must be final and definitive before the client >> can decide how to present or process the body. > >I'm not sure how to interpret your position here PHK, but this would be >a major step backwards for the Web. My position is that :status can *never* go into trailers (which I think should be unsupported btw.) HTTP/1 has always worked this way: The first thing the server tells you is the status code, and there is no way it can change that subsequently: Once you've seen 200, 301, 404 or 502, you know what use the object body can be to you and dispatch accordingly. -- 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 Wednesday, 2 July 2014 09:56:49 UTC