Re: Hello from Mozilla

On 07/14/2009 06:51 PM, Ian Hickson wrote:

>> I want to avoid the following Squid bug report 5 years from now:
>>
>> Title: Squid breaks FooBar
>>
>> Comment1: FooBar, a WebSocket application, works fine unless there is a
>> "transparent" Squid proxy in the way. I have attached a packet trace.
>>
>> Comment2: Closed as invalid. Squid seems to be handling the HTTP
>> messages correctly. Squid is not responsible to what happens after
>> Upgrade, inside the tunnel.
>>
>> Comment3: Reopened as critical. I need to make this work. Please do
>> something! I have read somewhere that if Squid would not add a Via or
>> XFF header and also that extra space character after a column,
>> everything would just work!
>>
>> Comment4: Changed to enhancement: Rewrite Squid to support
>> WebSocket-compatible Upgrade exchange. Meanwhile, consider writing a
>> post-Squid eCAP module that will rewrite Squid-altered HTTP messages to
>> conform to WebSocket.
>
> If Squid changes the bytes that are sent from the client or by the server,
> then this bug will likely exist, yes. So don't do that. :-)

From HTTP point of view, some byte changes are not really changes and
some are actually required. Squid changes HTTP headers today and will
probably continue to do so 5 years from now, even when deployed as a
"man in the middle".

> If a man-in-
> the-middle proxy server modifies the bytes of connections it doesn't fully
> understand, then WebSocket isn't the only thing that will break.

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.

> (Note that a min-in-the-middle proxy is not the same as a "transparent
> proxy" as defined by the HTTP spec. Per spec, a "transparent proxy" is a
> proxy that does not modify the request or response beyond what is required
> for proxy authentication and identification.)

That is why I quoted "transparent". There is little transparent about
most "transparent" hijacking proxies. It is the reality that is not
covered by the HTTP specs but WebSocket will have to deal with it.
Moreover, I suspect similar arguments can be applied to surrogates and
even forward proxies that are covered by the specs and the specs allow
them to modify HTTP messages.

Cheers,

Alex.
Received on Wed Jul 15 2009 - 02:19:41 MDT