W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: trailers and pseudo-headers

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 02 Jul 2014 14:04:29 +0200
Message-ID: <53B3F54D.6070009@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC