Subject: CONNECT and HTTP/2.0

From: Martin Thomson <[email-masked]>
Date: Fri, 30 Aug 2013 10:30:54 -0700

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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 31 Aug 2013 16:35:39 -0700

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.

---

From: James M Snell <[email-masked]>
Date: Sat, 31 Aug 2013 16:56:51 -0700

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 (陈智昌)
<[email-masked]> wrote:
> https://chrome.google.com/webstore/detail/breakwall-vpn-spdy-proxy/higommoegggcanmkapeoohipckeofpnd
> (3000~ installs)
> *
> https://chrome.google.com/webstore/detail/spdy-proxy/hhihiednomfhmngipmplmgcngliajdnn
> (4000~ installs)
> 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 <[email-masked]>
> wrote:
>>

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 31 Aug 2013 17:40:29 -0700

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 <[email-masked]> wrote:

> support.
> > over HTTP/2.0. Please see:
> http://www.chromium.org/spdy/spdy-proxy-examples

---

From: James M Snell <[email-masked]>
Date: Sat, 31 Aug 2013 17:51:15 -0700

A pull request with edits against the current draft would work too :-)
On Aug 31, 2013 5:40 PM, "Ryan Hamilton" <[email-masked]> wrote:

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

---

From: Mike Belshe <[email-masked]>
Date: Sat, 31 Aug 2013 17:56:20 -0700

For others reading, the bug martin cites is here:
https://github.com/http2/http2-spec/issues/230

Martin - I believe the current text you have proposed would break the web.
 You'd no longer be able to CONNECT at all - if you happened to land at a
2.0 server, it would bounce you, and that is not backward compatible.  You
have no way, at this stage of negotiation, to know whether the server is
1.1 or 2.0.

I think its pretty safe to ignore the version header here.

Mike

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 31 Aug 2013 18:18:25 -0700

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.

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 31 Aug 2013 19:38:38 -0700

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 (陈智昌)
<[email-masked]>wrote:

> 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:
>>> I implemented the CONNECT over SPDY support in Chrome.  Here are a
>>> couple of docs we cooked up at the time
>>>
>>> On Sat, Aug 31, 2013 at 4:56 PM, James M Snell <[email-masked]>wrote:
>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 31 Aug 2013 19:42:32 -0700

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 <[email-masked]> wrote:

> On Sat, Aug 31, 2013 at 6:18 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>> * 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
>> * The :path header value contains the authority-form of the
>> 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.
>>
>>

---

From: Ilya Grigorik <[email-masked]>
Date: Sat, 31 Aug 2013 20:17:41 -0700

I'll second Will's comments.. this is anything but theoretical.

There is also a large number of users relying on Chrome + node-spdyproxy:
https://github.com/igrigorik/node-spdyproxy/.

On Sat, Aug 31, 2013 at 4:35 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> https://chrome.google.com/webstore/detail/breakwall-vpn-spdy-proxy/higommoegggcanmkapeoohipckeofpnd(3000~ installs)
> *
> https://chrome.google.com/webstore/detail/spdy-proxy/hhihiednomfhmngipmplmgcngliajdnn(4000~ installs)
> On Fri, Aug 30, 2013 at 10:30 AM, Martin Thomson <[email-masked]
> > wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 31 Aug 2013 22:04:06 -0700

On 31 August 2013 18:18, William Chan (陈智昌) <[email-masked]> wrote:
> 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.

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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 31 Aug 2013 23:28:05 -0700

On Sat, Aug 31, 2013 at 10:04 PM, Martin Thomson
<[email-masked]>wrote:

> too)?

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?

>  (And it will compress less well.)  Can we just say that its value is

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.

> intent is to have them in a single HTTP/2.0 frame.  That might need

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.