jet
jet copied to clipboard
mpenet
Ring middleware
The normal ring middleware doesn't expect a channel as a valid response (same for channel as body). So far I saw that middleware that fail are: session cookies
True, all the middlewares that mess with responses or bodies could cause unexpected results if you use the features of jet that are out of the RING spec (chunked bodies, async response).
I am not sure there's a way to make it compatible without rewriting all middlewares in the wild to support jet... and I am not sure I am willing to take that route. However if I would do it, it would be (a) separate project(s) as I don't want to bring in tons of dependencies to jet, and probably only done for some very common middlewares such as the ones you're mentioning.
I'll think about it.
The way http-kit does it, without re-implementing any middleware, is to stop function execution at the innermost function (your own handler), and only when the response is processed and ready, your handler continues and the "out" part of the middleware is processed with the response.
So basically, the middleware never sees the Channel response, only a regular RING response.
This requires the developer to write his code inside a "with-channel" expression, in the http-kit case.
Maybe this helps.
I didn't dig deep but I don't believe this is how it works in http-kit (please prove me wrong, I'd be curious to see how it is achieved there).
see https://github.com/http-kit/http-kit/blob/master/src/org/httpkit/server.clj#L45-L48
If you want mostly compatible ring handlers you can use body channel as your async channel and leave the ring handler synchronous, it will send headers when your handler returns and the body later as you feed it data, it should be just as efficient.
I ll think about it more anyway (busy lately, but hopefully in the next few days).
You're right, about http-kit - if it's a websocket connection, it just sends a 100 response back which passes the middleware fine. After that the connection is upgraded so no problem to work async without middleware.
If it's the long-polling/ajaxy stuff, I think it doesn't return a response until the server sends something (like I suggested in my previous comment) because that will close the HTTP connection, and the point is to simulate a full-duplex websocket-like connection here.
So in both cases the middleware is not required to process a channel-as-response going out, so middleware keeps working.
Right. It's doable relatively easily for the websocket part. For the long polling part I don't believe this allows full compatibility depending on what the middlewares are doing (ex: modifying :body, expecting it to be of a RING compatible type, etc)..
In any case, I don't have enough free time to tackle this at the moment, but will do by xmas for sure.
Thanks for the feedback.