Is there a way to use this with a different webserver?

[iffy]

I'd like to use websock but just ran into this line, which forbids any HTTP method except GET:

nim-websock/websock/http/server.nim

Line 52 in 691f069

if header.meth notin {MethodGet}:

I'm guessing that means you'd like the websock HTTP server to remain a WebSockets-only server? If that's the case, are there any examples of using websock within a different HTTP web framework (jester? chronos?)? Or would you accept a PR that allows for POST requests?

[jangko]

I never tested it before, maybe need some tweaks. handleRequest is actually not too dependent on a particular HTTP server.
The only thing you need to make sure is you can provide HttpRequest object, and the HttpRequest itself is a composition of chronos components.

nim-websock/websock/websock.nim

Line 252 in 691f069

proc handleRequest*(

[arnetheduck]

I think in general it would be good to enable the possibility of multiple "protocols" on a single "http" port - ie we need this for nimbus as well since we want websockets and "regular" json-rpc to coexist without having to run two http servers (and ideally metrics and rest also) - any step towards the the possibility of mixing and matching websockets, normal http requests and also server side event streams would be good to have in general, though this would require the http server part to become extensible / pluggable - not sure what's possible today cc @cheatfate

[dryajov]

It shouldn't be too hard to make the HTTP part pluggable, we can replace the HttpRequest object that handleRequest expects by either a generic that has the expected shape or a dynamically dispatched interface (the former is preferable)... The request object should allow reading/writing headers and responses. So, it would be possible to for example wrap a raw chronos HttpRequest object and use that instead of the default websock HttpRequest. Full HTTP support, was beyond the scope of the library at the time it was implemented and use cases like this were supposed to be handled by a reverse proxy or similar, still making the HTTP part pluggable is easy and should most likely be supported.