ons 2012-03-14 klockan 14:18 +1300 skrev Amos Jeffries:
> huh? it says exactly what protocol the tunnel is intended to contain
> (switch to).
On GET/OPTIONS yes, but only for the transport, not tunnel.
You can use Upgrade on CONNECT as well if you want. But it's for the
client<->proxy only and says nothing about the contents of the tunnel
requested by CONNECT.
CONNECT www.example.com:80 HTTP/1.1
Upgrade: TLS/1.0
Connection: Upgrade
instructs the proxy that the client wishes to have the client<->proxy
connection wrapped in TLS/1.0. If the proxy agrees it sends a HTTP/1.1
101 Switching Protol response and any further communication from that
point is wrapped in SSL client<->proxy, without changing the tunnel (it
may still be SSH, IMAP, SMTP or whatever).
> Only so far as HTTP hops are concerned. The data inside the tunnel may
> well be another CONNECT request opening more hops *after* the end.
Yes, and any other form of nesting. As I said CONNECT do not say
anything about the encapsulated protocol. It's just a request for a
bidirectional tunnel to the requested endpoint.
> My reading of the Upgrade RFC is that when sent on CONNECT is it a
> request for the recipient to be the end of the HTTP end-to-end tunnel
> part and turn itself into that Upgraded type.
Upgrade is defined in HTTP/1.1.
The TLS/1.0 upgrade token is defined in the now deprecated rfc2817.
neither uses Upgrade in combination with CONNECT.
rfc2817 defines CONNECT as a method to forward Upgrade over proxies by
encapsulating the Upgrade request within a CONNECT.
> For a bit of perspective: We could take a GET with Upgrade:, send it
> unchanged to a peer and treat the resulting TCP connection as an
> Upgraded tunnel over which native X traffic happens. No different to
> handling a CONNECT today.
Clients may only send Upgrade together with Connection: Upgrade as it's
a hop-by-hop directive, so any proxying of the directive would
technically be a protocol violation.
Regards
Henrik
Received on Wed Mar 14 2012 - 02:16:35 MDT
This archive was generated by hypermail 2.2.0 : Wed Mar 14 2012 - 12:00:07 MDT