Re: CONNECT and HTTP/2.0

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?


>
> 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
that.


> 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.