-
Notifications
You must be signed in to change notification settings - Fork 3
Thoughts on interfacing with existing servers
Given that direct IO access is required to support WebSockets, Server-sent events, and even some features of HTTP/2, it's difficult to imagine how a HTTP web server like Nginx fits into this picture, other than acting as a simple proxy for the sake of serving static files and directing requests to other application on the same IP address.
The first things that need to be defined are the responsibilities of the web server, and the mechanism for dispatching requests and/or connections to the application. Rack Next will need to implement it's own simple multi-threaded HTTP web server that supports the WebSocket upgrade handshake among a few other extras, and have the ability to directly pass protocols it doesn't understand through to the application. It's difficult to imagine how any web server could be anything more than a proxy to Rack Next. What else could a web server possibly help with that doesn't make the specification more complicated?
Once the connection is established, the handshake completed, and the application instantiated, the application has full responsibility of that connection. The web server at this point only manages stale connections.
If the application specification for Rack Next dictates that the application must take an IO stream as input and output, it should technically be possible to run an application (for testing or simulation purposes) using only STDIN and STDOUT.