On Mon, Oct 15, 2012 at 02:35:57PM +0200, Milan Babuskov wrote:
> On Mon, Oct 15, 2012 at 1:25 PM, Willy Tarreau <[email protected]> wrote:
> >> I'll try Windows version of Safari to see if I could reproduce the problem.
>
> Well, Safari 5.1.2 on Windows works without any problems both with and
> without http-server-close, so no luck there.
So most likely it's only old outdated safari using an experimental protocol
version which is affected.
I have rechecked the old versions to refresh my memories :
- draft 75 was about an exact byte-matching handshake which is totally
incompatible with HTTP relaying since it doesn't talk about headers
or HTTP messaging but really bytes on the wire. This one was eliminated
2.5 years ago for this precise reason. Anyone still using this has no
chance to ever see his client work ; Also the framing used was subject
to some vulnerabilities which could be used to corrupt intermediary
caches.
- draft 76 was even more incompatible with relaying as it broke the
HTTP sequencing by expecting the proxies or servers to forward some
data that were not advertised as content-length. The result is that
the client gets stuck waiting for the server to respond, and the
server gets stuck waiting for the client to send the data. The framing
had the same issues as above. Similarly people using such an outdated
browser will never be able to reach a websocket site.
It's worth understanding that these were early design versions which have
nothing to do with the WebSocket protocol as it is now and which cannot
work by design. It's the principle of experimental specs. So there is really
nothing we can do to become compatible with these clients.
Maybe we should work instead on detecting such invalid clients and quickly
reject their requests instead of leaving them waiting for a timeout to
occur ?
They can be identified by the presence of the Upgrade header without the
Sec-WebSocket-Key header. So something like this would cleanly reject them :
http-request deny if { hdr_cnt(Upgrade) gt 0 } { hdr_cnt(Sec-WebSocket-Key)
eq 0 }
I don't know if such clients are used to display the response to the client,
otherwise we could even redefine the 403 error to send them a message inviting
them to replace their websocket-incompatible browser.
Regards,
Willy
