Re: CONNECT and HTTP/2.0

On Sun, Sep 1, 2013 at 8:10 AM, James M Snell <jasnell@gmail.com> 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
>
> +1 ... proposed spec text is always better than a bunch of links.
>

FYI, an I-D or pull request would require following a link :) But I agree
that the proposed spec text was more clearly stated that our previous
documentation on dev.chromium.org.


> My problem with this proposal is that it smells like a hack. If I was
> starting this from scratch, I'd likely propose that CONNECT would
> morph from it's current http-layer definition and into something that
> fits more naturally into the framing layer. For instance, rather than
> having a CONNECT method expressed via a normal HTTP flow, there would
> be a CONNECT frame type that would establish the tunnel independent of
> the regular http semantics. But that's just me and I have to admit
> that I don't have any skin in this particular part of the game.
>

FWIW, I don't care too much either. I just object when people say that we
should *remove* an existing feature in HTTP. That will break backwards
compatibility with HTTP/1.X, which will block adoption (I already pointed
out that my browser can't switch fully without this feature).


> Whatever is done here, we just need to make sure there is clear spec
> text written in the draft, not links off to some other website.
>

Hah, of course. Doesn't that always go without saying? :P Lol.


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