Re: Handling HTTP Upgrade requests
On Tue, 2015-03-10 at 21:59 +0100, Andy Wingo wrote: On Thu 26 Feb 2015 08:51, Nala Ginrut nalagin...@gmail.com writes: 3. I have to mention that the current inner server is not non-block and weak for slow-header-DDOS. Indeed. I think the right solution is cothreads. What do you think? Yes, it's my answer too. ;-) For more clearly, NIO + cooperative threads. If it's BIO, then it works fine with normal/good requests, but halts with the intended tricky formatted bad requests. Sometimes it could halt long time when you upload bigger file. That's what current Artanis suffering from. But could be solved easily with Nginx reverse-proxy. Anyway, this issue is not only about NIO, there're large room for optimizing though. PS: To those who care, unfortunately, Guile has no epoll/kqueue yet, that's one of the reasons why I want to write new server core for Artanis. ;-) The wip-ethreads branch has something like this. Perhaps that could serve for inspiration :) Yes, it's good start for me. Years ago, Mark once gave me a warn that a good non-blocking design may need to change something in Guile-core, especially ports. But it's not an easy work to make the whole Guile support non-blocking in short time. Dunno if it's still true for current Guile. My plan is to provide restricted non-blocking I/O cautiously. Of course, I'm optimistic to expect Guile support better non-blocking from long term perspective. ;-)
Re: Handling HTTP Upgrade requests
On Thu 26 Feb 2015 08:51, Nala Ginrut nalagin...@gmail.com writes: 3. I have to mention that the current inner server is not non-block and weak for slow-header-DDOS. Indeed. I think the right solution is cothreads. What do you think? PS: To those who care, unfortunately, Guile has no epoll/kqueue yet, that's one of the reasons why I want to write new server core for Artanis. ;-) The wip-ethreads branch has something like this. Perhaps that could serve for inspiration :) Andy -- http://wingolog.org/
Re: Handling HTTP Upgrade requests
David Thompson da...@gnu.org skribis: I've been tinkering with adding WebSockets[0] support to Guile's HTTP arsenal. The first blocking issue I've come across is that an HTTP server must be able to detect the Upgrade header[1] and change protocols. In my case, once a client thread accepts a WebSocket connection, it should speak the WebSocket protocol, not HTTP. Roughly, I would change ‘http-write’ in (web server http) to just remove the socket from the server’s poll set when the response is an upgrade, no? Ludo’.
Re: Handling HTTP Upgrade requests
Hi David! IMHO, there's no HTTP header anymore once you've done handshake successfully, but sending frame defined by WebSocket. For this case, once handshake is successful, I think you have to spawn a new server instance (or use callbacks, depends on your server architecture design) rather than using Guile inner HTTP server to manage this socket. Or it'll be cracked while parsing HTTP header as you pasted. One of the possible way is to build a WebSocket gateway to dispatch the connections to each server instance (or callbacks) and managing handshake for each connection. Anyway, to support WebSocket, one have to customize the server core. The Guile inner server is dedicated to be the HTTP one, IIRC. That's why I stopped development of websocket module in Artanis, since I have to write its new async server core first. ;-) On Sat, 2015-02-21 at 18:00 -0500, David Thompson wrote: I've been tinkering with adding WebSockets[0] support to Guile's HTTP arsenal. The first blocking issue I've come across is that an HTTP server must be able to detect the Upgrade header[1] and change protocols. In my case, once a client thread accepts a WebSocket connection, it should speak the WebSocket protocol, not HTTP. Here's an example of a backtrace that you'd see after a successful WebSocket handshake, when the client tries to actually make use of the socket: In ice-9/boot-9.scm: 171:12 3 (with-throw-handler #t #procedure 1720560 at web/... #) In web/server/http.scm: 126:17 2 (#procedure 1720560 at web/server/http.scm:125:15 ()) In web/request.scm: 204:31 1 (read-request #closed: file 0 ()) In ice-9/boot-9.scm: 106:20 0 (#procedure 10ce380 at ice-9/boot-9.scm:97:6 (thr... ...) ERROR: Bad request: Bad Request-Line: \x81\x86B\x93�Q Does anyone have an idea about how to approach this problem? Thanks in advance! [0] http://www.websocket.org/ [1] http://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header
