[WEBSOCKET_SPEC-188] Interaction with Servlet Filters, Listeners and RequestDispatchers is unclear Created: 18/Apr/13  Updated: 18/Apr/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The spec is unclear as to when ServerEndpointConfig instances registered with a ServerContainer and Endpoint onOpen methods are invoked.

Consider a JSR356 enabled servlet container with the following mappings

/* SomeFilter
/foo/bar/* FooBarServlet
/foo/

{param}

/* MyEndpointConfig
/other/* OtherServlet

Is the SomeFilter doFilter method invoked for a websocket upgrade request to /foo/bar/info ?

If so, does the getServletPath method return the mapping for the FooBarServlet or the MyEndpointConfig? What happens if the filter wraps the request, can this effect the matching to an EndpointConfig?

If the checkOrigin method returns false, is the request then handled normally by the Filter and Servlet?

If a websocket upgrade request is received with a URI of /other/info, can the OtherServet use a RequestDispatcher.forward to /foo/bar/info and have the connection accepted by the MyEndpointConfig ?

Similarly, are ServletRequestListener instances called before/after websocket handshake handling and if so, what is the getServletPath set to?






[WEBSOCKET_SPEC-176] Specification does not specify who should send Pings and how often Created: 25/Mar/13  Updated: 07/Dec/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Nick Williams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags: container, ping, pong

 Description   

The WebSocket spec does not specifically say who is responsible for sending ping messages and how often they should be sent. I think this is a serious problem, as it could be confusing to application developers. I assumed the container did that, but the Tomcat implementation does not (and I do not know whether that's a bug in the Tomcat implementation or part of the spec). The Javadoc for PongMessage and @OnMessage talk about receiving pongs, but nothing there says "you have to manually send pings in order to receive pongs" or something like that.

Assuming application developers are required to manually send pings, I think that's a potential problem. If users are solely responsible for sending ping messages, then we have immediately created a situation where (in many/most cases) the developer is responsible for creating and maintaining one or more threads to manage the sending of pings. This can add quite a lot of development overhead and testing to applications. Additionally, in some environments (such as Servlet containers) an application creating its own threads can be problematic (memory leaks, etc.). Ideally, the container would manage the sending of pings in order to avoid this situation.

To be the most flexible, @ServerEndpoint, @ClientEndpoint, ServerEndpointConfig, and ClientEndpointConfig should all probably have options to enable/disable, or configure the interval of, pinging, with it defaulting to on (or some number of seconds) for server endpoints and off (or negative seconds) for client endpoints.



 Comments   
Comment by dannycoward [ 02/Apr/13 ]

The goal for this version was to give developers the API to send pings and pongs, but not to do anything but have the container respond to a ping with a pong. This is based on what the RFC 6455 says about the ping/pong mechanism.

Its not clear from that description if websocket applications will want ping/pongs at some regular interval, or use them only very rarely, or something imbetween. So that's why the API has just provided the API to send and receive. I believe the API on RemoteEndpoint.sendPing/sendPong is relatively clear on how to send them manually.

We may well revist this in the next version of the API - perhaps define some options for using pings and pongs in a more automated way.

Comment by Nick Williams [ 02/Apr/13 ]

I think this is problematic.

First, it is the server's (not necessarily the container's, just the "server"'s in general) responsibility to send pings. This is supported by the fact that the HTML5 WebSocket API provides no mechanism for sending pings or receiving pongs ... the spec says that browsers must simply respond to pings with pongs when the server sends them. Thus, you literally can't send pings from JavaScript.

So, as the spec is written, every server endpoint must implement its own mechanism for periodically sending pings. Because there is an instance of a server endpoint for each connected session, the "easiest path" that most developers will take is to create a new thread for each new session and use that thread to send a ping every X seconds. Terror and chaos will reign.

AT THE VERY LEAST, the container should be mandated to automatically send pings (for server endpoints only) at some fixed, pre-defined interval (of less than 30 seconds, since Chrome and FireFox close inactive WS connections after 30 seconds). Then, perhaps, in some later version we can add configurability for this (though I would argue the configurability is needed now, I know that's not going to happen). But NOT requiring the container to send pings for server endpoints WILL result in severe difficulties and problems for developers, and WILL open a can of worms in web applications.

Comment by Nick Williams [ 07/Dec/13 ]

I would love to get this further clarified for Java EE 8.





Generated at Mon Apr 27 09:23:39 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.