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

-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 <grmocg@gmail.com> 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 <jasnell@gmail.com> 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.
>>
>

Received on Monday, 1 July 2013 17:00:56 UTC