websockify and named pipe timeouts on win32

[totaam]

Issue migrated from trac ticket # 1211

component: platforms | priority: major | resolution: fixed | keywords: win32 websockify

2016-05-29 07:48:54: antoine created the issue

---

For some unknown reason, sockets refuse to go into blocking mode on win32, causing all sorts of problems.
The patch attached tries to workaround this issue by wrapping the send and recv methods, but still fails to allow win32 to use websockify reliably as the http server code calls socket.sendall from its flush function, and this cannot be overriden.

[totaam]

2016-05-29 07:49:35: antoine uploaded file html5-win32.patch (8.7 KiB)

try to use blocking socket everywhere and wrap win32 non-blocking socket calls

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed

[totaam]

2016-08-15 07:41:11: antoine uploaded file websockify-win32.patch (3.8 KiB)

allow websockify to run on win32

[totaam]

2016-08-15 10:00:58: antoine commented

---

As of r13352 (+ minor fixup in r13355), we can use the websockify html5 server on win32. Websockify still needs the [/attachment/ticket/1211/websockify-win32.patch], which I will try to upstream, at least in part.

[totaam]

2016-09-25 16:59:09: antoine changed status from new to closed

[totaam]

2016-09-25 16:59:09: antoine set resolution to fixed

[totaam]

2016-09-25 16:59:09: antoine commented

---

Some related changes in #1298#comment:3, websockify re-fixed on win32 in r13866 + r13867: use a high timeout for http (high enough that we have time to service requests), only apply the socket workaround for websockify traffic.

Play platform bug whackamole for a few more hours: r13870 + r13872: I can now connect with the html5 client to all servers, including shadow servers on win32 and osx, and including through the proxy (made easier by the new username and password fields: r13869 + r13873)