Websocket support for the servlet backend about http4s-servlet HOT 15 OPEN

If I look at the early Jetty 9 implementation it works with Servlet 3.0. I assume it is sufficient enough.

from http4s-servlet.

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.

from http4s-servlet.

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.

from http4s-servlet.

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

from http4s-servlet.

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.

from http4s-servlet.

+1, bump it.

On Wed, Dec 3, 2014 at 11:36 AM, Ross A. Baker [email protected]
wrote:

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
http4s/http4s#15 since it's half done
already, and paves the way toward this.

—
Reply to this email directly or view it on GitHub
#7.

from http4s-servlet.

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.

from http4s-servlet.

Do I understand correctly that websocket support only works with Blaze and not Servlet?

from http4s-servlet.

@ijuma at the present time that is correct.

from http4s-servlet.

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.

from http4s-servlet.

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.

from http4s-servlet.

@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 Request => F[WebSocket] shape, then I think it could be done with the servlet JSRs.

from http4s-servlet.

This is implemented in Jetty 10. Not a huge priority, but we can give this another go.

from http4s-servlet.

Bump. Is this moribund now? We use Tomcat 8 and http4s 0.21 and are considering Websockets.

from http4s-servlet.

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 WebCnnection, it seems the rest would snap into place.

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.

from http4s-servlet.