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

Re: CONNECT and HTTP/2.0

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>
Message-ID: <20130901191035.GA10070@LK-Perkele-VII>
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.


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.

Received on Sunday, 1 September 2013 19:11:01 UTC

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