- From: Brian Pane <brianp@brianp.net>
- Date: Mon, 18 Jul 2011 02:43:06 -0700
- 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 example). The caching proxy would be allowed to start sending additional SPDY requests to the server upon receipt of the SYN_STREAM in step 3. -Brian
Received on Monday, 18 July 2011 09:43:37 UTC