Hi folks,
We've been building up a collection of smaller issues so I wanted to get
a few of those out of the way. Please take a look:-
* Should session.getRequestURI() include the query string ?
http://java.net/jira/browse/WEBSOCKET_SPEC-136
I was thinking: yes it should. But note that the equivalent method on
the servlet API doesn't. Note we also have a separate method for
returning the query string on Session. Does anyone have a problem
clarifying this to include the query string ?
* Clarify WebSocketContainer#set/getMaxSessionIdleTimeout()
http://java.net/jira/browse/WEBSOCKET_SPEC-140
If I recall correctly, the idea was for the WebSocketContainer to hold
the default timeout for sessions. So that new sessions created in that
container would assume that as their default value for
Session.get/setTimeout(), which can be overridden on a per session basis
using the session method.
The fix would be to clarify this default-on-the-container, override on
the session behavior. And also rename the methods:-
New: WebSocketContainer#set/getDefaultMaxSessionIdleTimeout() and
Session#set/getMaxIdleTimeout().
Let me know if anyone sees this one differently.
* What happens if an incoming message is too big ? Give as an error to
the developer or close the connection ?
http://java.net/jira/browse/WEBSOCKET_SPEC-137
At first I thought that we could raise the error and pass it to the
developer. But Mark raised the uncomfortable scenario that this would
mean that the peer that send it would have sent a message that its
remote endpoint would not have processed at all.
So I am also thinking that in this case, the receiving container should
immediately close the connection, and send back the client
CloseCode.TOO_BIG (1009), and a suggestion to include something helpful
in the close reason, like the message limit.
Thanks,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation