jetty.project/jetty-websocket
Joakim Erdfelt 8dba440317 Issue #3279 - WebSocket Close Refactoring
+ FrameFlusher "close" frames are detected during
  enqueue and sets the state properly for failing
  other frames after it
+ Moving away from Blockhead(Client|Server) to using actual implementations
+ Moved tests to /jetty-websocket-tests/ to be able to use actual impl
  for both sides of testcase (client and server)
+ Corrected FrameFlusher terminate/close to not fail the close frame
  itself, but only frames that arrive AFTER the close frame.
+ Moving WebSocketCloseTest to jetty-websocket-tests to avoid
  using BlockheadClient / BlockheadServer in testing
+ Cleanup of unnecessary modifiers on interface
+ Logging error if @OnWebSocketError is undeclared
+ IOState removed
+ New ConnectionState tracks connection basics in a simpler
  method then IOState did.
+ No tracking of Remote close initiated (not needed)
+ IncomingFrames.incomingError() removed
+ Session delegates to Connection for all state changes
+ Errors can be communicated to application multiple times
+ Close is only communicated once

Signed-off-by: Joakim Erdfelt <joakim.erdfelt@gmail.com>
2019-02-15 10:07:24 -05:00
..
javax-websocket-client-impl Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
javax-websocket-server-impl Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
jetty-websocket-tests Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
websocket-api Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
websocket-client Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
websocket-common Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
websocket-server Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00
websocket-servlet Happy new year!! (#3232) 2019-01-01 11:52:16 +10:00
README.TXT renamed README.txt to README.TXT and updated contents 2013-08-29 00:32:36 +10:00
pom.xml Issue #3279 - WebSocket Close Refactoring 2019-02-15 10:07:24 -05:00

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.