Re: Hello from Mozilla

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 15 Jul 2009 18:39:27 +1200

On Wed, 15 Jul 2009 04:26:42 +0000 (UTC), Ian Hickson <ian_at_hixie.ch> 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
Received on Wed Jul 15 2009 - 06:39:33 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 16 2009 - 12:00:05 MDT