one server for http and ws

[ghost]

Hello! Many thanks for this simple ws server. I’ve tested it and it almost works perfectly for what I need. The one thing missing is the ability to serve normal HTTP requests from the same host:port as used for ws.

I’m wondering if another callback could be added to ws_events that is called with a socket and string containing the original http headers, such as:

void onnotws (int socket, const char *headers)

where socket is positioned just after the \r\n\r\n and headers contains everything up to that position.

Then I could handle everything, close the socket and return.

Looking at the code I can sort of imagine it could be done by calling do_handshake() before the socket is added to the client list and calling onnotws() if it fails. But there’s other details too so before hacking too much I thought I would ask if it was something you would like to add properly.

Thanks for your time.

[Theldus]

Hi @pidloop,
Thanks for your compliments,

The idea of passing on the connection headers to the user is not new and has already been requested in issue #39.
Since some websockets servers provides this type of information, I do plan to implement it in the future, but it will only be for the connection header, not message headers.

Unfortunately, supporting two protocols would diverge too much from my original idea of having a simple websocket server, and would require a lot more work.

In the future, I'm thinking about supporting two kinds of APIs: simple ones (like the current one) and more "manual" ones. This second API would give users more control over sockets, connections, and so on, allowing them to work with HTTP implicitly.

This idea is described in greater detail in issue #47, but it requires significant changes to the current code and will not be implemented anytime soon.

---

Idea: Since you want to listen to an HTTP server and WebSocket on the same port, why not use a proxy?

Nginx is able to, through the request headers, forward the connection to an HTTP or WebSocket server. This HTTP server can be Nginx itself or one of your own.

[ghost]

Thanks for your thoughts. Will monitor for future progress.

This is a small embedded IoT project, so no chance for help from a normal webserver. Easiest solution is just two ports but then the ws port has to be embedded in the html page javascript and another firewall port opened for it and I wanted to avoid that.

So if you don't mind I will pull out your frame handling code and take it from there. Will certainly leave a clear trail back to your origins. Again, thanks for a great ws solution base.

[ghost]

Ok, I have it running. Quite simple actually:

• added a new callback onnonws() to ws_events called when a non-websocket http request arrives
• added a field to ws_cli_conn_t to store the http header
• ws_establishconnection() reads the header and preloads it into ws_frame_data.frm
• do_handshake uses this instead of reading the header from the socket
• if do_handshake fails, call onnonws()

Now echo.c is a complete mini-server that can serve both files (such as itself) and support web sockets. Changed files attached.
wsServer-changed.tgz

Thanks again for doing all the hard part (handshake and framing).

[Theldus]

Hi @pidloop,
*Very interesting*

I really liked how you did it: there were no major changes, but it still works as expected.

Unfortunately, I still intend to only support WebSockets, but I will refer to this discussion whenever such question comes up =).

However, your changes gave some ideas that may be useful in some way: as I previously stated, I do intend to save the request header and make it accessible later (as in #39). If I add "on_error" support on top of that (as proposed in #66), the user could detect 'HTTP connection attempts' through the 'on_error' callback and act accordingly (the 'sendFile' would be handled inside the "on_error", and etc).

This might still require the user to make some changes to the server, but it would already provide pretty much everything the user needed to do so.

--
In any case, I'm happy that my wsServer is being useful.

On occasion, I see random forks with structural changes on the server, and I'm happy that this src can still be readable enough to be hacked to suit particular user needs =).

[ghost]

Good to hear it might be of some us.

The only other change I've made is to make ws_sendframe() and friends return the payload count that was sent, instead of including the frame overhead. My thinking is this is more in line with the usual "send" and "write" style functions. The change was just one line, the last line becoming:

return ((int)(output - idx_first_rData));

Again, many thanks for sharing the heavy lifting part of this, most appreciated.

BTW, my app is named HamClock which you can find here. It's targeted towards amateur radio operators and others with an interest in monitoring space weather conditions. It's actually an X Windows program but for some time it has supported a build option that allows any browser to connect to it directly and operate it remotely without needing any X at all. But that used zillions of XMLHttpRequests mainly because I already know how to do it that way. Now I've found the time to learn enough about WebSockets to use them in the next release and the performance improvement is dramatic, not to mention the code is simpler on both ends as well. So this has been a most interesting and worthwhile learning experience.

All the best.