bde86467f4
* Issue #3806 async sendError Avoid using isHandled as a test withing sendError as this can be called asynchronously and is in a race with the normal dispatch of the request, which could also be setting handled status. The ErrorHandler was dispatching directly to a context from within sendError. This meant that an async thread can call sendError and be dispatched to within the servlet container at the same time that the original thread was still dispatched to the container. This commit fixes that problem by using an async dispatch for error pages within the ErrorHandler. However, this introduces a new problem that a well behaved async app will call complete after calling sendError. Thus we have ignore complete ISEs for the remainder of the current async cycle. Fixed the closing of the output after calling sendError. Do not close if the request was async (and thus might be dispatched to an async error) or if it is now async because the error page itself is async. * updates from review * better tests * revert ignore complete * added some TODOs * more TODOs * fixed rename * cleanup ISE and more TODOs * refactored to call sendError for uncaught exceptions rather than onError * more of the refactor * extra tests for sendError from completing state Reworked HttpChannelState and sendError so that sendError is now just a change of state. All the work is done in the ErrorDispatch action, including calling the ErrorHandler. Async not yet working. Additional tests Converted ERRORED state to a separate boolean so it can be used for both Sync and Async dispatches. Removed ASYNC_IO state as it was just the same as DISPATCHED The async onError listener handling is now most likely broken. WIP making sendError simpler and more tests pass WIP handling async and thrown exceptions WIP passing tests Improved thread handling removed bad test Implemented error dispatch on complete properly more fixed tests sendError state looks committed - Added resetContent method to leave more non-content headers during sendError - Fixed security tests - simplified the non dispatch error page writing. Moved towards being able to write async * fixed gzipHandlerTest * Updated handling of timeout errors. According to servlet spec, exceptions thrown from onTimeout should not be passed to onError, but just logged and ignored: If an exception is thrown while invoking methods in an AsyncListener, it is logged and will not affect the invocation of any other AsyncListeners. * This changes several tests. * Dispatcher/ContextHandler changes for new ERROR dispatch handling. Feels a bit fragile! * Fixed tests in jetty-servlets * Fixed tests in jetty-proxy * more test fixes * Fixed head handling reverted unnecessary changes Improved reason handling WIP on fully async error handling. Simplified HttpChannelState state machines to allow for async actions during completing more WIP on fully async error handling. sendError and completion are not both non-blocking, without using a startAsync operation. However we are lacking unit tests that actually exercise those code paths. * Simplified name of states Added test for async completion * Cleanups and javadoc * Cleanups and javadoc * remove snake case * feedback from review * Write error page into fixed pooled buffer Use the response to get/release a pooled buffer into which the error page can be written. Make it a fixed sized buffer and if it overflows then no error page is generated (first overflow turns off showstacks to save space). The ErrorHandler badly needs to be refactored, but we cannot change API in jetty-9 * More test fixes for different error page format * minor cleanups * Cleanup from Review * Fixed javadoc * cleanups and simplifications * Cleanup from Review * renaming and some TODOs * Cleanup from Review * Checkstyle fixes * Cleanup from Review * Code cleanups and simplifications * fixed debug * Cleanup from Review * Ensure response sent before server shutdown * removed unnecessary optimisation * fixed duplicate from merge * Updates from review Signed-off-by: Greg Wilkins <gregw@webtide.com> |
||
|---|---|---|
| .. | ||
| javax-websocket-client-impl | ||
| javax-websocket-server-impl | ||
| jetty-websocket-tests | ||
| websocket-api | ||
| websocket-client | ||
| websocket-common | ||
| websocket-server | ||
| websocket-servlet | ||
| README.TXT | ||
| pom.xml | ||
README.TXT
This is the jetty websocket module that provides a websocket server and the skeleton of a websocket client.
By default websockets is included with a jetty release (with these classes either being in the jetty-websocket jar or in
an aggregate jar (see below).
In order to accept a websocket connection, the websocket handshake request is first routed to normal HTTP request
handling, which must respond with a 101 response and an instance of WebSocketConnection set as the
"org.eclipse.jetty.io.Connection" request attribute. The accepting behaviour is provided by WebSocketHandler or the
WebSocketServlet class, both of which delegate to the WebSocketFactory class.
A TestServer and TestClient class are available, and can be run either directly from an IDE (if jetty source is
imported), or from the command line with
java -cp jetty-aggregate/jetty-all/target/jetty-all-7.x.y.jar:jetty-distribution/target/distribution/lib/servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestServer --help
java -cp jetty-aggregate/jetty-all/target/jetty-all-7.x.y.jar:jetty-distribution/target/distribution/lib/servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestClient --help
Without a protocol specified, the client will just send/receive websocket PING/PONG packets. A protocol can be specified for testing other
aspects of websocket. Specifically the server and client understand the following protocols:
org.ietf.websocket.test-echo
Websocket messages are sent by the client and the server will echo every frame.
org.ietf.websocket.test-echo-broadcast
Websocket messages are sent by the client and the server will echo every frame to every connection.
org.ietf.websocket.test-echo-assemble
Websocket messages are sent by the client and the server will echo assembled messages as a single frame.
org.ietf.websocket.test-echo-fragment
Websocket messages are sent and the server will echo each message fragmented into 2 frames.