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: Sat, 31 Aug 2013 23:28:05 -0700
Message-ID: <CAA4WUYj7AgoBHRovKW098djqs4dO_HYsSqiBFrY3qDOvbMOYzw@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 Sat, Aug 31, 2013 at 10:04 PM, Martin Thomson

> 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

> Note that changing what colon-headers are required, especially
> prohibiting :scheme is going to be a little bit of a surprise to some.
>  (And it will compress less well.)  Can we just say that its value is
> ignored instead?

I just picked what we did in SPDY, which we didn't spend too much thinking
about since it works. I don't think I care too much about this particular
bike shed, so if we want to ignore :scheme, I'd tolerate that. Not excited
about ignoring stuff, but if that's what others would prefer, I'd accept

> Other issues: this tunneling will limit the size of TLS frames if the
> intent is to have them in a single HTTP/2.0 frame.  That might need
> some mention.

I'm not sure if this needs any mentioning...I mean, the same applies to TLS
over TCP, right? If anything, I'd put it in the TLS spec that having a TLS
record span multiple frames in the underlying transport can incur delays in
processing a TLS record.
Received on Sunday, 1 September 2013 06:28:33 UTC

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