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

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.
>