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: Jeff Pinner <jpinner@twitter.com>
Date: Mon, 1 Jul 2013 10:09:16 -0700
Message-ID: <CA+pLO_hRZVLcD6KFaR5XqU+T4oDxRo+fo7+9kxfVB23RWTt+nQ@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 17:09:45 UTC

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