I’ll look into what you suggested, but as a general followup to this, what would make the most sense for the WebSocket API to be able to receive these intercepted requests? I’m looking at the old net/websocket API as a reference, and it appears that the only supported server API is using ws-serve, which binds to a port and listens on it.
I think I’d want to implement some sort of simpler interface that would allow passing the I/O ports on to the WebSocket implementation, which would then return a websocket connection object. Does that seem reasonable? Is there specific idiomatic way of doing that sort of thing using the web server? As an aside, I’m actually trying to port some code written as a Node.js server to Racket. Specifically, I’m using the Express library for the routing. This is what the main server file looks like (actually written in CoffeeScript): https://gist.github.com/lexi-lambda/c6da899cfa1d808b9338 <https://gist.github.com/lexi-lambda/c6da899cfa1d808b9338> I like the elegance of this sort of extensible routing system (I require the express-ws module, which extends the server to include websocket routing support). What would be the closest analogue in the Racket web server with the idea of that sort of “extensible” routing? Thanks for the help, Alexis > On Mar 21, 2015, at 19:26, Jay McCarthy <jay.mccar...@gmail.com> wrote: > > The Web server models applications as "servlet : request -> response" > and there's no way to go from the request to the original HTTP > connection. > > In contrast, the Web server has a lower level concept of a > "dispatcher" that receives a parsed HTTP request AND the connection > object (which has the I/O ports). If the WebSocket handshake has the > sender start with a correctly formatted HTTP request, then this is > what you want and you'd go from using something like serve/servlet to > using something like serve/launch/wait and dispatch/servlet with > another layer of dispatching. > > On the other hand, if the handshake doesn't have a complete request, > then you'd need to customize the dispatching server directly with a > new kind of read-request and request structure that can stop in the > middle. I think what I'd do is make a super-struct and re-use > everything from the HTTP server when the handshake isn't there. > > Jay > > On Sat, Mar 21, 2015 at 8:44 PM, Alexis King <lexi.lam...@gmail.com> wrote: >> The WebSocket handshake is intentionally implemented in such a way so that >> WebSocket connections can be performed using the same port that the HTTP >> server is running on. This is implemented by making the handshake a standard >> HTTP 1.1 GET request with an “Upgrade: websocket” header. >> >> I’m interested in doing this using the Racket web server, but I’m not sure >> how to intercept websocket connections. I’m completely willing to implement >> all the websocket connection logic myself, I just need to know how to detect >> headers sent with that Upgrade header before the web server has a chance to >> handle them so that I can pass the connection off to my own websocket logic. >> >> What’s the proper way to achieve this sort of thing? >> >> Alexis >> ____________________ >> Racket Users list: >> http://lists.racket-lang.org/users > > > > -- > Jay McCarthy > http://jeapostrophe.github.io > > "Wherefore, be not weary in well-doing, > for ye are laying the foundation of a great work. > And out of small things proceedeth that which is great." > - D&C 64:33 -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
