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

Re: CONNECT and HTTP/2.0

From: James M Snell <jasnell@gmail.com>
Date: Sun, 1 Sep 2013 08:10:08 -0700
Message-ID: <CABP7Rbdj8eSHAEAmFtvF8fsrds7oGsckVBJ2T+cKvkwVvV1S9Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: William Chan (陈智昌) <willchan@chromium.org>, Ryan Hamilton <rch@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.

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

- 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.
Received on Sunday, 1 September 2013 15:10:55 UTC

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