W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #300: Define non-final responses

From: Brian Pane <brianp@brianp.net>
Date: Mon, 18 Jul 2011 02:43:06 -0700
Message-ID: <CAAbTgTuuZPKe=hBc6qA4_0CxpKLmjC40WMjtehz-v43tKfNqoQ@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jul 18, 2011 at 1:55 AM, Willy Tarreau <w@1wt.eu> wrote:

> What I'm wondering is how would an HTTP-to-SPDY gateway work. Let's imagine
> that we have a caching proxy which always adds an "Upgrade: SPDY/1.0" header
> into all outgoing requests so that compliant servers may tentatively upgrade.

I think what would need to happen in this scenario is:

1. The server generates a SPDY stream ID.  The simplest correct
implementation, if I've read the latest SPDY draft correctly, is to
use a stream ID of 2.
2. The server sends an HTTP 101 response.
3. The server sends a SPDY SYN_STREAM frame to create a unidirectional stream.
4. The server sends the response headers as a SPDY HEADERS frame.
5. The server sends the response body, packaged into one or more SPDY
data frames.  The last of these frames contains a SPDY (not TCP) FIN.

This looks similar to SPDY's server-push mechanism, but it's not quite
the same thing.

If I got the mapping right, the server would be able to send the
entire response (steps 2-5) without waiting for any more HTTP or SPDY
messages from its immediate client (the caching proxy in this

The caching proxy would be allowed to start sending additional SPDY
requests to the server upon receipt of the SYN_STREAM in step 3.

Received on Monday, 18 July 2011 09:43:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC