-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Websocket support for the servlet backend #7
Comments
If I look at the early Jetty 9 implementation it works with Servlet 3.0. I assume it is sufficient enough. |
I think we should focus on making it work portably in Servlet 3.1, and then we can look for backward compatibility using proprietary APIs if there is demand. It should work on Jetty >= 9.1 and Tomcat >= 8. I'm adding code to detect the Servlet API for http4s/http4s#15. From there, I think we can implement an HttpUpgradeHandler and extract the Blaze implementation for frame parsing. I looked at JSR 356, and it looked awkward to me. |
I have a feeling this is going to have some sweeping effects on websocket support such as the types etc, so I'm going to close the older, likely stale issues that will probably be covered. |
Also agree that we should focus on making it work cleanly with Servlet 3.1, and maybe provide backends for things like Atmosphere on earlier versions Similar to what I plan to do with sessions, it makes sense to just make an abstract websocket API, and have one of its backends as "servlet" (which would imply Servlet 3.1), if you don't run Servlet 3.1 then you can plugin a different backend |
Enough other nice things are getting done, I think we should bump this from 0.5. I'd still like to finish http4s/http4s#15 since it's half done already, and paves the way toward this. |
+1, bump it. On Wed, Dec 3, 2014 at 11:36 AM, Ross A. Baker [email protected]
|
Tomcat 8 seems to support upgrades to arbitrary HttpUpgradeHandlers. Jetty 9, on the other hand, does this. It appears that we're not going to be able to support web sockets via the vanilla servlet 3.1 API. |
Do I understand correctly that websocket support only works with Blaze and not Servlet? |
@ijuma at the present time that is correct. |
In theory, we should be able to use an HttpUpgradeHandler with new async I/O support and share a lot of the code with Blaze. In practice, Jetty never initializes the handler. The standard servlet way of doing web sockets is JSR 356, but that seems to want to map its own handler to known paths. I haven't quite worked out how to integrate that into our model. So I feel like we're close, but that's where we got stuck. Ideas welcome, because I'd like to see this implemented. |
Jetty's is still not implemented. I think if we had a WebSocketServletFactory hanging around, we might be able to forward requests to that when we want to perform an upgrade. We'd need a JettyHttp4sServlet instead of an Http4sServlet, but I suspect this could work. |
@jmcardon has shown interest in this. Upgrade handling is still not implemented in Jetty. I continue to believe that this can't be done on a servlet while maintaining the "websocket is embedded in a plain HTTP Response" model. If we had a special |
This is implemented in Jetty 10. Not a huge priority, but we can give this another go. |
Bump. Is this moribund now? We use Tomcat 8 and http4s 0.21 and are considering Websockets. |
I couldn't make it work several years ago, but I still think the key to fit it into the existing model is to implement an HttpUpgradeHandler. Once you get that Tomcat has a WsHttpUpgradHandler, but it steers toward that WebSocket JSR that doesn't fit the other backends' model. I think it could be inspirational, however. |
My kneejerk reaction to both is yes.
The text was updated successfully, but these errors were encountered: