- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 02 Jul 2014 14:04:29 +0200
- To: Michael Sweet <msweet@apple.com>
- CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014-07-02 13:12, Michael Sweet wrote: > Julian, > > On Jul 2, 2014, at 3:43 AM, Julian Reschke <julian.reschke@gmx.de> wrote: >> On 2014-07-02 09:35, Poul-Henning Kamp wrote: >>> In message <53B3AD3A.8020307@gmx.de>, Julian Reschke writes: >>> >>>> The reason I ask is that people might start putting ":status" into a >>>> trailer and expect that to have an effect (it would be nice to have that >>>> feature, but it wouldn't map to 1.1...). >>> >>> It would also be pretty pointless: It would just shift the buffering >>> responsibility from the server to the client. >> >> 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). > > As you've noted, you can't do that in HTTP/1.1, and in fact this would be a case where I would emit 100 (continue) to the client to let them know they can continue sending data, then follow up with a final status code (200, 500, whatever) once I'd processed the message body and any trailers in the request. When I said "streaming" I was referring to the process of sending the payload in the response. There are many cases where a server would say "200", and then start a complicated process that might fail half-way. In HTTP/1.1, signalling an error in this situation is hard (abort the chunked transfer or close the connection). It would be good if HTTP/2 can do better here. Best regards, Julian
Received on Wednesday, 2 July 2014 12:05:11 UTC