websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-211

Remove restriction on when a server endpoint can be deployed

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      Section 6.4 explicitly restricts server endpoints from being deployed once the server is up and running:

      Developers may deploy server endpoints programmatically by
      using one of the addEndpoint methods of the ServerContainer
      interface. These methods 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 however when it is useful to have consolidated handling of HTTP requests including WebSocket handshake requests. For example SockJS (a protocol for WebSocket fallback options) expects URLs (see the "Session URLs" section) with the pattern "/endpointPrefix/<server>/<session>/<transport>" where <transport> can be HTTP-based (e.g. HTTP streaming, long polling) or WebSocket. The most natural way to implement this is to create a single servlet SockJS that handles all requests under "/endpointPrefix" including requests for "/endpointPrefix/*/*/websocket". This is known as front servlet and it's what virtually all web frameworks have.

      I can imagine there are other cases where it is not possible to determine the URL at which an endpoint should be deployed at startup (e.g. SAAS product that lets configure and use cloud-based services). It would be useful to have more examples here.

      It's worth pointing out that WebSocket APIs in Java and outside of Java consistently provide a way to do this, i.e. integrate WebSocket handshakes into existing HTTP request handling mechanisms (Jetty 9, Netty, vert.x, socket.io, etc.)

        Issue Links

          Activity

          Hide
          martin_grigorov added a comment -
          Show
          martin_grigorov added a comment - This request is related to https://java.net/jira/browse/WEBSOCKET_SPEC-181 .
          Hide
          rstoyanchev added a comment -

          Based on the experience with a similar request in Tomcat, I want to clarify what I have in mind is the ability to initiate an upgrade from a Servlet or Filter, which is different from deployment via ServerContainer.addEndpoint. Something along the lines of:

          HandshakeRequest request = ...
          HandshakeResponse response = ...
          
          ServerContainer container = ... 
          
          container.upgrade(request, response, endpoint);
          

          The above is not a concrete proposal, it's just an example to make clear the intent of the request.

          Show
          rstoyanchev added a comment - Based on the experience with a similar request in Tomcat , I want to clarify what I have in mind is the ability to initiate an upgrade from a Servlet or Filter, which is different from deployment via ServerContainer.addEndpoint. Something along the lines of: HandshakeRequest request = ... HandshakeResponse response = ... ServerContainer container = ... container.upgrade(request, response, endpoint); The above is not a concrete proposal, it's just an example to make clear the intent of the request.

            People

            • Assignee:
              Unassigned
              Reporter:
              rstoyanchev
            • Votes:
              13 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated: