Re: CONNECT and HTTP/2.0

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?

=====

8.3 The CONNECT method

The HTTP pseudo-method CONNECT [RFC2817] is used to convert an HTTP/1.1
connection into a tunnel to a remote host. CONNECT is primarily used with
HTTP proxies to established a TLS session with a server for the purposes of
interacting with https resources.

In HTTP/2.0, the CONNECT method is used to establish a tunnel over a single
HTTP/2.0 stream to a remote host. The HTTP header mapping works as mostly
as defined in 8.1.2.1, with a few differences. Specifically:
* The :method header value is CONNECT
* The :scheme header field MUST be omitted.
* The :host header MAY be sent. It exists for backwards compatibility with
HTTP/1.1 implementations where the Host header may not match the host
indicated in the authority specified in the request-target of the CONNECT
request.
* The :path header value contains the authority-form of the request-target
of CONNECT requests.

=====

I note that it's tempting to omit the :host header, but my primary concern
is that it may introduce backwards compatibility issues in HTTP/1=>HTTP/2
gateways, as I don't know how HTTP/1 implementations currently handle the
case where the Host header does not match the host specified in the
request-target of CONNECT requests.


On Sat, Aug 31, 2013 at 5:51 PM, James M Snell <jasnell@gmail.com> wrote:

> A pull request with edits against the current draft would work too :-)
> On Aug 31, 2013 5:40 PM, "Ryan Hamilton" <rch@google.com> wrote:
>
>> I implemented the CONNECT over SPDY support in Chrome.  Here are a couple
>> of docs we cooked up at the time
>>
>> http://www.chromium.org/spdy/spdy-proxy-examples
>> http://www.chromium.org/developers/design-documents/secure-web-proxy
>>  http://www.chromium.org/spdy/spdy-proxy
>>
>>  The first is the most concrete.  I could write up a I-D for this, if
>> that's the right way forward.  However, it seems like the behavior of
>> CONNECT on an HTTP/2 stream is pretty much identical to the behavior of
>> CONNECT on an HTTP/1 connection.
>>
>> Cheers,
>>
>> Ryan
>>
>>
>>
>> On Sat, Aug 31, 2013 at 4:56 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>>> If CONNECT support is critical, then my recommendation would be for
>>> y'all to make a more formal proposal and document how it's supposed to
>>> work in the form of an I-D. Currently the details on how this would
>>> work are somewhat muddy.
>>>
>>> On Sat, Aug 31, 2013 at 4:35 PM, William Chan (陈智昌)
>>> <willchan@chromium.org> wrote:
>>> > This is fine for now, but FYI I consider this a blocker for Chromium to
>>> > switch entirely to HTTP/2.0. I note that this is an existing HTTP
>>> feature
>>> > that clients use to tunnel over HTTP proxies. As far as its use in
>>> SPDY,
>>> > it's not merely theoretical, but has a number of actual uses:
>>> >
>>> > *
>>> >
>>> http://spdylay.sourceforge.net/package_README.html#shrpx-a-reverse-proxy-for-spdy-https
>>> > *
>>> >
>>> https://chrome.google.com/webstore/detail/breakwall-vpn-spdy-proxy/higommoegggcanmkapeoohipckeofpnd
>>> > (3000~ installs)
>>> > *
>>> >
>>> https://chrome.google.com/webstore/detail/spdy-proxy/hhihiednomfhmngipmplmgcngliajdnn
>>> > (4000~ installs)
>>> > * Corporate google.com VPN extension (not public) (widely used by
>>> Googlers)
>>> >
>>> > I believe these uses demonstrate that this is a desired use case to
>>> support.
>>> > As noted, it is fairly straightforward to define a mapping of HTTP
>>> CONNECT
>>> > over HTTP/2.0. Please see:
>>> http://www.chromium.org/spdy/spdy-proxy-examples
>>> > and http://www.chromium.org/spdy/spdy-proxy.
>>> >
>>> >
>>> > On Fri, Aug 30, 2013 at 10:30 AM, Martin Thomson <
>>> martin.thomson@gmail.com>
>>> > wrote:
>>> >>
>>> >> Folks might notice that I've added a section on CONNECT to HTTP/2.0:
>>> >>
>>> >> http://http2.github.io/http2-spec/index.html#rfc.section.8.3
>>> >>
>>> >> This doesn't close #230, it simply documents status quo.  If we decide
>>> >> to support CONNECT, the draft will, of course, be updated to reflect
>>> >> that decision.  This is fairly straightforward based on the Chromium
>>> >> documentation and the discussion thus far, we just need to decide if
>>> >> it's valuable enough to do.
>>> >>
>>> >
>>>
>>>
>>