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