netty, haproxy, websockets v76

Marc Hämmerle mail at no7hing.com
Sun Jun 26 17:24:58 EDT 2011


When haproxy is used in http-mode it splits incoming upgrade-requests for websockets as the nonce (8 byte) in the body of the request is not http-compliant. The Server then acknowledges that he's indeed capable of handling websockets, replies with the first part of the response-header and handles the nonce and second part of the response-header afterwards (working Python/Tornado solution: http://groups.google.com/group/python-tornado/browse_thread/thread/fdc3d62c5b3725aa).

The problem - besides a totally broken WebSocket 76 spec - is that netty won't decode(via the HttpRequestDecoder in the pipeline) the incoming http request when the nonce is not present; in my handler just the handler for the channel connect is called, but not the handler for received messages - so the connection times out.

This works (as far as netty is concerned):

# request begin
GET /ws/ HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost
Origin: http://localhost
Sec-WebSocket-Key1: 290  q =2 9y 7,41  t   q #18U
Sec-WebSocket-Key2: 56  4} 61 494  6

12345678
# request end

but this doesn't work:

# request begin
GET /ws/ HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost
Origin: http://localhost
Sec-WebSocket-Key1: 290  q =2 9y 7,41  t   q #18U
Sec-WebSocket-Key2: 56  4} 61 494  6


# request end


Can anybody point me in the right direction to solve this, without implementing a HttpRequestDecoder from the ground up? Is this a bug or is it intended behaviour?


Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20110626/83580c10/attachment.html 


More information about the netty-users mailing list