- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 03 Jan 2012 13:36:48 +1300
- To: igor.faynberg@alcatel-lucent.com
- CC: Torsten Lodderstedt <torsten@lodderstedt.net>, ietf-http-wg@w3.org, oauth@ietf.org
On 1/2/2012 7:07 AM, Amos Jeffries wrote:
>> On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote:
>> ...
>>>
>>> general note: I do not understand why caching proxies should impose
>>> a problem in case TLS is used (end2end). Could you please explain?
>>
>> Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP
>> hops). Proxies which decrypt TLS and provide responses out of cache
>> are already deployed in many places. Mostly in the form of
>> reverse-proxies, but corporate decryption proxies are also on the
>> increase.
>>
>> AYJ
On 3/01/2012 11:17 a.m., Igor Faynberg wrote:
> I am at a loss here; granted, it is a gray area... Does it mean that
> RFC 2817 has not been implemented properly?
>
From RFC 2817:
"
5. Upgrade across Proxies
As a hop-by-hop header, Upgrade is negotiated between each pair of
HTTP counterparties. If a User Agent sends a request with an Upgrade
header to a proxy, it is requesting a change to the protocol between
itself and the proxy, not an end-to-end change.
"
The more common case is CONNECT method from RFC 2068, from a user agent
to a reverse-proxy. Same behaviour.
> To make it simple: At the client, I establish a session key with the
> server, and then use it for confidentiality. How is this key known to
> any proxy?
"the server" is a proxy.
AYJ
Received on Tuesday, 3 January 2012 01:19:49 UTC