On 07/18/2012 09:39 PM, Amos Jeffries wrote:
> I'm working out how to implement Upgrade support
> around what bumping already does.
I do not think the two features are related.
> And yes that 101 will need to be implemented before we can claim
> full/proper RFC 2817 Upgrade support. I thought we could still support
> it in the existing bump fashion without the 101 though.
I do not see how. Any compliant client would expect 101 first.
>> Responding to a client CONNECT+Upgrade request
>> starts by sending 101 (Switching) and establishing a TLS connection with
>> the client. That is not bumping (we are not impersonating the server at
>> this stage). Bumping, if any, comes later, and does not depend on the
>> established TLS connection with the client.
>>
>> If bumping after Upgrade does happen, the client-proxy connection would
>> have these protocols:
>>
>> HTTP over bumped SSL/TLS over upgraded TLS over TCP
>>
>> while the proxy-server connection would have these:
>>
>> HTTP over bumped SSL/TLS over TCP
>>
>
> Er. So if I'm getting your point right. When implementing Upgrade:TLS we
> should do so before bumping
Yes.
> and disable the bump from happening?
No. The bumping decision does not depend on whether we upgraded
communication with the client or not. As far as bumping is concerned,
the client connection may have been upgraded to some FooBar17 protocol.
It would make no difference to what the bumping code has to do.
HTH,
Alex.
Received on Thu Jul 19 2012 - 03:46:40 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 19 2012 - 12:00:03 MDT