1. websocket-spec

Thorough list of smaller API, javadoc, spec suggestions based on the EDR draft


    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:


      This from Joakim Erdfelt from Intalio

      1) ServerContainer and ServerEndPointContainer are duplicate classes (removed in v008)
      2) DefaultClientConfiguration.getExtensions() will always return null. (fixed in v008)
      3) CloseReason.CloseCodes is missing 2 status codes. (these have been added in v008)
      They were proposed and accepted after RFC 6455 was final.
      Discussion here ...
      They are formally registered at
      4) There needs to be clearer javadoc on the CloseReason.CloseCodes as to the various rules around them. (Can only be sent by Server, only by Client, cannot be sent over connection, etc ...)
      5) Timeouts are declared as seconds, but in other network protocols timeouts are defined as milliseconds. Would recommend that we stick with the millisecond level accuracy. (milliseconds in v008)
      Example: http://docs.oracle.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout(int)
      6) Typo in ClientContainer.getMaxTextMessageBufferSize() "wed socket" (fixed v008)
      7) ClientEndpointConfiguration needs .setCookieStore(java.net.CookieStore) to satisfy authenticated user requirements.
      8) ClientEndpointConfiguration getter such as .getDecoders() and .getExtensions() (and probably all API getters) should be clear as to if they are allowed to return null, and if they are collections, should they always return a collection object, even if its empty? I see language about returning modifiable collections and whatnot, that's of great help, lets get more detailed please. (some fixed in v008, more to do)
      9) Need clarification if various collection setters, like ClientEndpointConfiguration.setEncoders() should use the collection as-is (helping with memory, but not with threading) or should copy the collection entries (if so, shallow or deep copy)?
      10) Various setExtension() .getExtension() javadoc should indicate if the <String> being referenced is a full ANBF extension (extension-token ";" extension-param), or just the extension name. (RFC-6455, Section
      Consider an ExtensionConfig interface instead.
      11) The default Session.getRemote() should use what <T> implementation? <Object>? (v008 removes T, was providing no extra checking for developers)
      12) Creating a new RemoteEndpoint for a difference in Object type is overly complex, how about ObjectSender RemoteEndpoint.getObjectSender(Foo.class) as an alternative approach? (thinking about this)
      That way we can perform the "am in the middle of a message?" check on that, the Writer, or the OutputStream to see if we can even start sending another message (yet).
      Keep in mind that if .getSendWriter() is active, no other .send*() method can be used until that Writer is closed (causing a FIN=true on the message)
      13) HandshakeRequest.getParameterMap() should include javadoc indicating that it is only URI Query parameters from GET requests only that will be returned. (All other request methods cannot be Upgraded)
      14) HandshakeRequest.getRequestURI() returns a URI object, yet the servlet-api returns a String object of the same method signature. (whoops, can't just wrap HttpServletRequest, have to copy the values now)
      15) HandshakeRequest.getRequestURI() should include javadoc to indicate what sort of information will be returned by this getter. For example, in the servlet-api, this will NOT return the query portion.
      16) Session.getInactiveTime() (and setInactiveTime()), need javadoc to indicate how if this affect physical or logical connections? (for example, on mux, the logical connection would be the place for this)
      17) Need some language on @WebSocketPathParam that this is only for server side websockets, not client side.
      18) The CloseReason.reasonPhrase has a limit on how big can be. (125 UTF8 bytes to be exact)
      Should the constructor truncate? or fail if the reason phrase is too big?
      (I favor truncation)


        dannycoward added a comment -

        these issues are all now resolved in v014

        dannycoward added a comment - these issues are all now resolved in v014
        dannycoward added a comment -

        Many of these issues have been integrated into v008. There are still a few left, so I am keep this issue open until v009.

        dannycoward added a comment - Many of these issues have been integrated into v008. There are still a few left, so I am keep this issue open until v009.


          • Assignee:
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: