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

Re: Issue #154: Sending a response before the request is complete

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 1 Jul 2013 11:14:20 -0700
Message-ID: <CAP+FsNfPioZkFr7VKPwBXfJsvn18-QB_xFKP=3XybxSkD6jHuQ@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
The only MUSTs here, with regard to consistency are:
1) any time a frame which contains a headers block is received, that data
MUST be processed by the decompressor, even when the results of this are to
be discarded.
2) a sender MUST serialize *and emit* any data emitted by the compressor.
It MUST NOT discard any such data, even when the stream has been
cancelled/reset.

Everything else is semantic layer.




On Mon, Jul 1, 2013 at 10:09 AM, Jeff Pinner <jpinner@twitter.com> wrote:

> Responses inline:
>
> On Mon, Jul 1, 2013 at 10:00 AM, James M Snell <jasnell@gmail.com> wrote:
>
>> -1, this is not just a question of best practices. For instance,
>> consider the following scenario:
>>
>> I send a GET request with a large number of request headers... the
>> first HEADERS frame contains the :path and :method headers, while a
>> later HEADERS frame contains an Authorization header and a
>> "cache-control: no-cache". If the server begins it's response
>> immediately after receiving the first HEADERS frame without waiting
>> for the complete header block to be received, then
>>
>> a) the compression state could get screwed up if the server attempts
>> to process an incomplete header block, and
>>
>
> There is a separate compression context in each direction -- the server
> sending the response HEADERS is independent of receiving any other request
> HEADERS frames.
>
> There is no risk of corrupting the compression state.
>
>
>
>> b) the server could end up sending the wrong data to the client
>> because it hadn't seen the Authorization or Cache-Control headers yet.
>>
>
> How is this any different than HTTP/1.1? I could respond to the request
> after reading the first line but before reading any headers -- which might
> be OK if I'm responding with a 503 and closing the connection.
>
>
>
>> If we are going to allow for header continuations, then we need to be
>> clear that a response cannot be sent until the request headers are
>> fully received, otherwise we can get into an inconsistent state.
>>
>
> We just need to be clear what frames constitute the complete set of
> "request headers." Nothing more needs to (or should) be said.
>
Received on Monday, 1 July 2013 18:20:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC