- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 01 Sep 2013 20:02:25 +1200
- To: ietf-http-wg@w3.org
On 1/09/2013 2:42 p.m., William Chan (陈智昌) wrote: > Sorry for the standardese. Please refer to > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-4.3.6 > and > 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, > > CONNECTwww.example.com:80 <http://www.example.com:80> HTTP/1.1 > > Cheers. > So "example.com:80" is a _path_ in your world? That kind of explains a few bugs we have with Chrome. I believe the empty scheme header, empty path header, and filled host header (both FQDN and port) to be the accurate representation. Amos > > On Sat, Aug 31, 2013 at 7:38 PM, Ryan Hamilton <rch@google.com > <mailto: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 <mailto: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 <mailto: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 > <mailto: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 <mailto: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 > <mailto: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 <http://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 > <mailto: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. > >> > > > > > > >
Received on Sunday, 1 September 2013 08:02:57 UTC