Re: Handling HTTP "Upgrade" requests

[Nala Ginrut <nalaginrut@gmail.com>]

On Wed, 2015-02-25 at 11:23 -0500, Dave Thompson wrote:
> IMO, an asynchronous/multi-threaded server is a separate issue. I was
> aiming for a solution that allowed a single websocket to be used on
> Guile's single-thread default web server.  Of course, the websocket
> implementation should be able to be applied to a more advanced server,
> should one be written.
> 

Ah I see.

> I think you're right that something in the default HTTP server must be
> changed, but I haven't grokked the implementation enough to figure it
> out.  AFAICT, the HTTP server socket needs to be handed over to a
> WebSocket server procedure, suspending additional HTTP request
> processing until the WebSocket is closed and the socket is handed back
> to the HTTP server.  Does that make some sense?  Things are too foggy
> for me to tell.

Personally, I don't think websocket part should be based on inner HTTP
server. Or there'd be some changes of the architecture.

But if you really want to use inner server, I think there're some points
to be noticed:
1. check if it's websocket frame, then call the registered handler and
skip read-request to avoid the problem you've pasted;

2. the current inner server detects keep-alive based on HTTP header, so
you have to modify something to support comet connection for websocket
ports.

3. I have to mention that the current inner server is not non-block and
weak for slow-header-DDOS. So if you handle one request in a long time,
others' requests will be blocked in a long time. One of the easy
solution is to take advantage of Nginx reverse-proxy. But it doesn't
solve all the issues. ;-P


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. ;-)

Happy hacking!