On Wed, 15 Jul 2009, Mark Nottingham wrote: > > Upgrade is hop-by-hop, so it's pretty limiting.
Do man-in-the-middle proxies count as a hop for the purposes of HTTP? As far as I can tell from the HTTP spec, the client is supposed to know whether it is speaking to a proxy or not, so man-in-the-middle proxies don't affect the hop-by-hop semantics... but it's not entirely clear. > Ian, an example: > > An intermediary (transparent, intercepting or whatever) can and often > does add arbitrary headers; e.g., x-forwarded-for. This is completely > legal in HTTP, where headers that are not understood are ignored, and > additionally several headers have provisions to change values in headers > as well (e.g., transfer-encoding, te, via, connection). > > They're also allowed to change the formatting of the message; e.g., > re-wrap headers, normalise whitespace. Sure, but that's why we have the TLS-over-port-443 option. In the cases where there is uncooperative network infrastructure, the client can just switch to that, and then there's no way the connection can be affected. > Specifying a bit-for bit handshake is incredibly fragile. Not doing so is unacceptably insecure for this use case, IMHO. We can't run the risk of Web pages hitting SMTP servers and sending spam, or poking at intranet servers, or who knows what else. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
