https://issues.apache.org/bugzilla/show_bug.cgi?id=55314
Bug ID: 55314
Summary: Provide option to allow programmatic deployment of
server (WebSocket) endpoint at runtime
Product: Tomcat 8
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: rstoyanc...@yahoo.com
JSR-356 explicitly states that the addEndpoint methods on ServerContainer "are
only operational during the application deployment phase of an application.
Specifically, as soon as any of the server endpoints within the application
have accepted an opening handshake request, the apis may not longer be used.
This restriction may be relaxed in a future version."
There are cases when it is useful to have consolidated handling of HTTP
requests including WebSocket handshake requests. For example SockJS [1] defines
a URL structure of the form "/endpointPrefix/<server>/<session>/<transport>"
where "transport" can be an HTTP-based (e.g. streaming, long polling) or
WebSocket (see the "Session URLs" section). The most natural way to implement
this is to create a single SockJsServlet that handles all requests under
"/endpointPrefix" including requests for "/endpointPrefix/*/*/websocket".
I'd like to propose that in the very least Tomcat make this possible through a
flag. I will also create a spec ticket to suggest it for the next iteration. I
think it's also worth considering whether this should be the default behavior,
with a flag being necessary only to revert back to strict compliance.
For what it's worth, pretty much all WebSocket APIs I'm familiar with (Java and
non-Java) do make it possible to create some kind of HTTP request handler that
can also initiate a WebSocket handshake. That includes the Tomcat 7
WebSocketServlet for which it's conceivable that some existing users may
realize this limitation when upgrading to Tomcat 8.
[1] http://sockjs.github.io/sockjs-protocol/sockjs-protocol-0.3.3.html
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
