On 07/04/15 11:04, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
forgot to include an example of a GET request from the tunnel:
GET / HTTP/1.1. Host: 192.98.102.30:8000. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Accept-Language: en-US,en;q=0.5. Accept-Encoding: gzip, deflate. DNT: 1. Sec-WebSocket-Version: 13. Origin: https://test.tutpro.com. Sec-WebSocket-Protocol: sip. Sec-WebSocket-Key: NKwlVvwJcj2Z07MlXm8URg==. Pragma: no-cache. Cache-Control: no-cache. X-Forwarded-For: 192.98.103.30. X-Forwarded-Host: 192.98.103.33. X-Forwarded-Server: jessie.test.tutpro.com.
since Connection, Upgrade and Sec-WebSocket-Version headers are missing, it looks to me that a modified version of ws_handle_handshake() would be needed.
I see Sec-WebSocket-Version header.
yes, i missed it.
Anyhow, if upgrade header is missing, isn't this just going to be bare http(s) connection? Or what is apache expecting to happen? To still upgrade to websocket?
i don't think so, but perhaps it should still include Sec-WebSocket-Accept header in 101 reply and add the connection to Websocket connection table?
It still not clear to me what is going (or expected) to happen afterwards. Will this connection be http or websocket? Because websocket requires framing of the data. Http stays tcp streaming connection.
Given that it is started as HTTP but no Upgrade is required, I guess that Apache is expecting to deal with http further. And then practically is not websocket and should not be considered as such.
Anyhow, perhaps you can look inside the websocket function and try to ignore the parts dealing with the missing headers. Then see what apache sends next. You can eventually send a 101 reply with some forged Sec-WebSocket-Accept from config file just to emulate and see the results. Then if it is websocket transmission, then websocket module can be adjusted to cope with this situation.
Cheers, Daniel