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: Sun, 1 Sep 2013 15:28:42 -0700
Message-ID: <CAA4WUYisWCKxHyV5+EV5FiJLRtcRCXbKtsuzsGbZR1uPtDoE5w@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>
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 Sunday, 1 September 2013 22:29:10 UTC

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