- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Wed, 02 Jul 2014 08:17:59 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In message <53B3BF49.9030207@gmx.de>, Julian Reschke writes: >>> What I meant is: an *additional* :status (such as in first claiming >>> everything is ok -- 200, then start streaming and failing, and then send >>> a 500 in the trailers). >> >> And if that is a risk, the client can do only one thing: Buffer the >> response, until it is sure what the :status will be. > >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. -- 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 08:18:21 UTC