Re: "Secure" proxies for HTTP URIs [was: new version trusted-proxy20 draft]

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




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