Upgrade is hop-by-hop, so it's pretty limiting.
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.
Specifying a bit-for bit handshake is incredibly fragile.
Cheers,
On 15/07/2009, at 3:26 PM, Adrian Chadd wrote:
2009/7/15 Ian Hickson <[email protected]>:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
WebSocket made the handshake bytes look like something Squid
thinks it
understands. That is the whole point of the argument. You are
sending an
HTTP-looking message that is not really an HTTP message. I think
this is
a recipe for trouble, even though it might solve some problem in
some
environments.
Could you elaborate on what bytes Squid thinks it should change in
the
WebSocket handshake?
Anything which it can under the HTTP/1.x RFCs.
Maybe I missed it - why exactly again aren't you just talking HTTP on
the HTTP port(s), and doing a standard HTTP upgrade?
Adrian
--
Mark Nottingham [email protected]
