- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 2 Jul 2014 19:58:43 +1000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: "Eric J. Bowman" <eric@bisonsystems.net>, "Julian F. Reschke" <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Personally - very strong +1. This is fundamental. Yes, it sucks, but it’s how HTTP works, and we can’t change it here. On 2 Jul 2014, at 7:56 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > 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. -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 2 July 2014 09:59:13 UTC