Re: CONNECT and HTTP/2.0

Sorry for the standardese. Please refer to
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-4.3.6and
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#section-5.3.

Copied from p1 section 5.3:

   authority-form

   The authority-form of request-target is only used for CONNECT
   requests (Section 4.3.6 of [Part2
<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#ref-Part2>]).
 When making a CONNECT request
   to establish a tunnel through one or more proxies, a client MUST send
   only the target URI's authority component (excluding any userinfo) as
   the request-target.  For example,

     CONNECT www.example.com:80 HTTP/1.1


Cheers.


On Sat, Aug 31, 2013 at 7:38 PM, Ryan Hamilton <rch@google.com> wrote:

> Looks good to me, with one question.  What is the "authority-form of the
> request-target of CONNECT requests"?
>
>
> On Sat, Aug 31, 2013 at 6:18 PM, 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?
>>
>> =====
>>
>> 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.
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>
>>
>