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

From: James M Snell <[email-masked]>
Date: Mon, 1 Jul 2013 10:00:05 -0700

-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

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.

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.

On Fri, Jun 28, 2013 at 10:41 PM, Roberto Peon <[email-masked]> wrote:
> I could see adding a blurb which states that headers are not complete unless
> they're complete, but otherwise, this is HTTPbis as opposed to HTTP/2
> material, I think?
> -=R
>
>
> On Fri, Jun 28, 2013 at 10:35 PM, James M Snell <[email-masked]> wrote:
>>
>> https://github.com/http2/http2-spec/issues/154
>>
>> Suggested add to the HTML mapping...
>>
>> ---
>> The server MUST NOT begin sending the response header block
>> until it receives all of the request headers from the
>> client; however, the server MAY begin sending the response
>> immediately after receiving the request headers without waiting
>> for the complete request payload or trailers to be received.
>> ---
>>
>> Since we added HEADER continuations, there is a risk that a server
>> might begin its response to a request prematurely, without waiting for
>> the complete set of headers to be received. Doing so could cause quite
>> a few major issues including caching problems.
>>
>> While this is not something that we can strictly enforce as a MUST, it
>> is something that servers really ought to do.
>>
>

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 1 Jul 2013 10:09:16 -0700

Responses inline:

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

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

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Jul 2013 11:12:57 -0700

On 1 July 2013 10:09, Jeff Pinner <[email-masked]> wrote:
> We just need to be clear what frames constitute the complete set of "request
> headers." Nothing more needs to (or should) be said.

I'm with Jeff here.  There are plenty of cases where ":path" alone is
completely sufficient to produce a response.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 1 Jul 2013 11:14:20 -0700

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.