another quick update, adding a content-length: 16 header in my socket.io instance(note that's not part of the websocket draft). nginx will forward the handshake response properly. and chrome and safari will establish a websocket connection which works only server -> client. i explained it a bit more detailed in irc


14:02 [ timebomb ] no
14:02 [ timebomb ] server to client
14:02 [ timebomb ] there's 2 problems
14:03 [ timebomb ] no.1 when you make a high timeout proxy connection, nginx will assume the websocket frames are just the rest of the previous html response. so it will keep forwarding the websocket requests from the server back to the client
14:03 [ timebomb ] however the frontend side isn't able to send data back over that same connection
14:04 [ timebomb ] no.2 once the websocket connection is established the framing is something like 00 data ff
14:04 [ timebomb ] it will look like this:
14:04 [ timebomb ] 127.0.0.1 - - [21/Nov/2010:13:28:27 +0100] "GET /socket.io/websocket HTTP/1.1" 101 589 "-" "-"
14:04 [ timebomb ] 127.0.0.1 - - [21/Nov/2010:13:28:27 +0100] "\x00~m~4~m~~h~1#" 400 173 "-" "-"
14:04 [ timebomb ] nginx will return a 400 bad request answer
14:05 [ timebomb ] the best solution i can think of right now is to wrap that request in a html get at frontend side and then unwrap it internally at the proxy side
14:07 [ timebomb ] also i needed to add a content-length: 16 header to my node.js handshake response and a content-length: 8 internally in nginx for the handshake request otherwise nginx would drop the websocket key 3
14:08 [ Evet ] things getting more complicated
14:09 *** netzsportler [~netzsport@p57BA40B2.dip.t-dialin.net] has quit [Ping timeout: 245 seconds]
14:09 [ timebomb ] about that wrap and unwrapping ... it would be easily avoided if there was a way to avoid the html filter chain once the connection is established
14:09 [ timebomb ] i just don't know how and if that's possible