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