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

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.