+ Adding new RFC declared close codes 1011 (CLOSE_SERVER_ERROR) and
1015 (CLOSE_FAILED_TLS_HANDSHAKE)
+ Adding support for responding as CLOSE_SERVER_ERROR if an unhandled
exception (similar to how HTTP error 500 works) but for exceptions
thrown out of implementations of WebSocket.
+ Adding guard to prevent use of CLOSE_FAILED_TLS_HANDSHAKE on
close control frame.
+ Adding unit test for the CLOSE_SERVER_ERROR case.
+ Adding unit test for HTTP response 400 on bad Sec-WebSocket-Version
request header value.
While performing a SSL write triggered by an application thread that is not
dispatched by the NIO layer, process() may read and decrypt bytes that will
be kept in the _unwrapBuf buffer.
However, the application needs to parse these bytes, but parsing is normally
performed only from handle() by a thread dispatched by the NIO layer.
The fix is to detect if there are unparsed bytes at the end of process(), and if
so, call asyncDispatch() to eventually call handle() to parse those bytes.
This follows commit ff29a1cc51 for JETTY-1322.
The reason to remove the guard is that the channel may be closed multiple times, and if for any reason
a check to the idle timestamp triggers, then the idle callback is invoked, but it's not really idle: it is
already closed.
When used with SSL, this causes a truncation attack exception thrown by SSLEngine, because the idle
callback causes a shutdown of the SSLEngine without having received a SSL close alert.
warnings.
+ Splitting out WebSocketConnection#handshake() into new
WebSocketServletConnection interface and refactoring accordingly,
in order to remove servlet-api dep on WebSocketConnection for
appropriate websocket client use.
+ revert last change using maven-shade-plugin as it didn't address
the now redundant transitive dependencies present in the
jetty-websocket pom.
+ made a formal jetty-aggregate/jetty-websocket build instead.
This is now implemented, using the new architecture of wrapping the connection with
SslConnection.
The only refactoring was to avoid that the HTTP handshake was sent from the
HandshakeConnection constructor, because at that point the SSL wiring is not ready yet.
Now the handshake is sent from handle(), guarded by a boolean variable to sent it once.
Greg Wilkins
Joakim Erdfelt
Jan Bartel
Simone Bordet
Jesse McConnell