On Wed, 15 Jul 2009 04:26:42 +0000 (UTC), Ian Hickson <[email protected]> wrote: > 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? Byte 5 through to the first of: two CRLF or one NULL byte. Specified as step 1 through 11 by the looks of it. Correctly operating: * MUST remove the "Upgrade: WebSocket\r\n" bytes. * MUST add "Via: 1.1 " followed by an arbitrary length and content string. * SHOULD add a Date: header (position optional, suggested to be between GET and Host:). Though Squid does not (yet) do this, other proxies and future fully HTTP compliant Squid might. Conditionally: * Depending on the local network topology _sometimes_ proxies required to alter the section labeled "the path" in order for the request to even happen. Changing it from ( "/" path ) to ( "http://"; hostname "/" path ) ** The http://hostname part MAY be removed again before passing to Server. Usually not. To raise the extreme end of the problem: In HTTP a proxy MAY go so far as to sort the headers alphabetically and expect things to still work well. The solutions you need to be looking at are: * using HTTP Upgrade as per the HTTP spec, with full flexibility. * using ports other than 80. * sending requests as pure binary and dropping the HTTP look-alike bits Amos
