Websocket support for the servlet backend

[rossabaker]

1. Does this require Servlet 3.1?
2. If so, are we going to continue to support Servlet 3.0 without?

My kneejerk reaction to both is yes.

[arouel]

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

[rossabaker]

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.

[bryce-anderson]

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.

[mdedetrich]

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

[rossabaker]

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.

[bryce-anderson]

+1, bump it.

On Wed, Dec 3, 2014 at 11:36 AM, Ross A. Baker notifications@github.com
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.

[rossabaker]

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.

[ijuma]

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

[bryce-anderson]

@ijuma at the present time that is correct.

[rossabaker]

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.

[rossabaker]

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.

[rossabaker]

@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.

[rossabaker]

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