- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 27 Feb 2014 11:14:11 +1300
- To: ietf-http-wg@w3.org
On 2014-02-27 06:04, Peter Lepeska wrote: > That's pretty exciting. It's a shame there's not a better proxy > discovery > mechanism for plaintext HTTP 1.x traffic (maybe just an additional > response > header PROXY-AVAILABLE-AT: https://hostname:port) because it would mean > forward proxies could immediately provide HTTP2 benefits to their > users, > without having to wait for content servers to adopt HTTP2 and TLS. > > Peter Which party to the transaction would send that header and how would they determine its need to be added? * origin server or any reverse-proxy have no idea of forward-proxy client-facing capabilities. * client is obviously not in-band with the forward-proxy yet. * port 80 MITM cannot be trusted that much [1]. There is no 'permanent' version of 305 status code to redirect a client to a proxy. But that seems to be what we need. Something like 511 status but for proxy detection instead of auth detection. [1] IIRC one of the reasons for deprecating 305 were attackers utilizing 305 to redirect port 80 to a local proxy under their control. Amos > > On Wed, Feb 26, 2014 at 10:55 AM, William Chan (陈智昌) > <willchan@chromium.org>wrote: > >> Chromium indeed supports this today [1][2], and Firefox has indicated >> plans for future support, and Patrick seems to have whiteboarded it >> out [3]. >> >> [1]: https://developers.google.com/chrome/mobile/docs/data-compression >> [2]: https://sites.google.com/a/chromium.org/dev/spdy/spdy-proxy >> [3]: https://plus.google.com/+PatrickMcManusDucksong/posts/SnDYxHQoUiq >> >> >> On Wed, Feb 26, 2014 at 7:25 AM, Peter Lepeska >> <bizzbyster@gmail.com>wrote: >> >>> One question for browser vendors who have said they will not support >>> HTTP2 over plaintext (Firefox, chrome): will you support HTTP2 when >>> http-schemed URIs are being proxied via a Secure Proxy? >>> >>> This allows firefox and chrome users to get the performance benefit >>> of >>> HTTP2 at least across the segment between the ua and the proxy for >>> http-schemed URLs. >>> >>> Thanks, >>> >>> Peter >>> >>> >>> On Wed, Feb 26, 2014 at 5:37 AM, Amos Jeffries >>> <squid3@treenet.co.nz>wrote: >>> >>>> On 25/02/2014 8:49 p.m., Nicolas Mailhot wrote: >>>> > >>>> > Le Mar 25 février 2014 03:58, James Cloos a écrit : >>>> >> if anyone has a legal requirement to avoid end-to-end encryption, they >>>> >> MUST accomplish that by avoiding TLS between client and proxy. Such >>>> >> requirements MUST not affect the rest of us.) >>>> > >>>> > This forbids an http/1 use case and as such is outside the workgroup >>>> charter >>>> > >>>> >>>> There is also no sound reason so far presented behind forbidding >>>> that >>>> same use-case in HTTP/2. Just a few implementers choosing not to do >>>> it >>>> for reasons which have all be countered by other implementers who >>>> do. >>>> >>>> Also, in my (medium-low) familiarity with such laws TLS or any other >>>> mechanism used to transport packets to the collection point (proxy) >>>> is >>>> not relevant to the criterion placed upon the ISP. Only the ability >>>> to >>>> accurately and *fully* collect and report is prescribed. >>>> End-to-end TLS violates that legal requiremet, TLS-to-proxy does >>>> not. >>>> >>>> Amos >>>> >>>> >>>> >>> >>
Received on Wednesday, 26 February 2014 22:14:38 UTC