- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Sun, 1 Sep 2013 22:10:35 +0300
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, James M Snell <jasnell@gmail.com>, Ryan Hamilton <rch@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Aug 31, 2013 at 11:28:05PM -0700, William Chan (陈智昌) wrote: > On Sat, Aug 31, 2013 at 10:04 PM, Martin Thomson > <martin.thomson@gmail.com>wrote: > > > On 31 August 2013 18:18, William Chan (陈智昌) <willchan@chromium.org> wrote: > > > I suck at editorial stuff so I expect people to object to my wording, but > > > here's some proposed text (I'd be happy to put together a pull request > > too)? > > > Does this clarify whatever you find muddy? > > > > This is exactly the sort of response I wanted to encourage. The only > > problem I see with your proposed text is that it says nothing about > > what forms the tunnel and its characteristics. Basically, I think > > that a full edit for this needs to take a good hard look at 2817. > > This is a good start, but there's a bit more required. > > > > Yeah, I didn't really know how to spec that. Basically, the DATA frames > form the bidirectional tunnel. I'm not quite sure what else to say here, > but I have difficulty because my natural thought process matches what we > did in SPDY, so I don't know how to discuss this in a way that would clear > up any other possible tunnel characteristics. Do you have any proposed text > here? Regarding :scheme, what about fixing it to 'tcp' (with possiblity of some other kind of CONNECT be specified later)? And as I said before (for the part after tunnel has established): Client <-- HTTP2 stream ---> Proxy <-- TCP connection --> Server 1) If DATA frame is received from the client: - Send its payload to the server. 2) If END_STREAM is received from the client: - Flush any buffered to to the server (including this DATA frame payload if any). - Send end-of-data to the server. 3) If stream error is received from the client. - Send TCP reset to the server. 4) If data is received from the server: - Send the data to client in DATA frame(s). 5) If end-of-data is received from the server: - Flush any buffered data to the client as DATA frame(s). - Send a frame with END_STREAM (possibly on the last DATA frame). 6) If reset is received from the server: - Send stream error to client. Basically: HTTP2 DATA <---> TCP data. HTTP2 END_STREAM <--> TCP end-of-data. HTTP2 stream error <--> TCP reset. But this only works with TCP. If SCTP or something is to be supported, things get much more complex. -Ilari
Received on Sunday, 1 September 2013 19:11:01 UTC