Re: CONNECT and HTTP/2.0

in all this didcussion about CONNECT, I presume that references to 
server, are to be interpreted as proxy?

Since CONNECT is for proxies only.

Or is it being proposed this could be useful for end servers?

Adrien


------ Original Message ------
From: "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>
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>
Sent: 2/09/2013 7:10:35 a.m.
Subject: Re: CONNECT and HTTP/2.0
>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 21:38:09 UTC