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

Re: CONNECT and HTTP/2.0

From: 陈智昌 <willchan@chromium.org>
Date: Mon, 9 Sep 2013 08:36:20 -0700
Message-ID: <CAA4WUYgAzNXU1wetYPMBxS0XQngnpP9kT2MnhPDxtzxz3YYE9w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, Ryan Hamilton <rch@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
Any further thoughts on this? Should I put together a pull request?

On Sun, Sep 1, 2013 at 3:28 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> On Sun, Sep 1, 2013 at 11:07 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
>> On 31 August 2013 23:28, William Chan (陈智昌) <willchan@chromium.org>
>> wrote:
>> > Yeah, I didn't really know how to spec that. Basically, the DATA frames
>> form
>> > the bidirectional tunnel.
>> Then that's what you say :)
>> > I'm not quite sure what else to say here, [...]
>> The only thing that probably needs looking into is the effect that
>> tunneling has on what the TLS layer will probably treat like TCP.
>> That is, note how this potentially differs from TCP.  Frame sizes can
>> be dealt with easily enough, but you also need to consider how it
>> closes.  Maybe this leads to a requirement to treat END_STREAM like
>> FIN (just as RST_STREAM is analogous to RST).
> I was naturally assuming that END_STREAM==FIN in the tunnel. I guess we
> need to specify it? How about adding the following paragraph:
> =====
> After successfully establishing a CONNECT tunnel over a stream, the stream
> DATA frames comprise the data of the bidirectional tunnel. Each direction
> of the tunnel is closed via the END_STREAM flag, similar to how TCP closes
> each direction with its FIN flag. RST_STREAM abnormally terminates the
> tunnel, similar to how TCP RSTs abnormally terminate the connection.
> =====
Received on Monday, 9 September 2013 15:36:47 UTC

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