websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-194

Clarify what is a valid WebSocket path spec syntax

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      As brought up in jsr356-experts:
      http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-04/message/6

      What would be a valid websocket path spec syntax?

      Some examples of GOOD path specs:

      "/bookings/

      {guest-id}

      " - section 4.1.1 and 4.3
      "/rewards/

      {vip-level}

      " - section 4.3
      "/hello" - section 2.1.4
      "/a/b/"
      "/a/

      {foo}

      "
      "/

      {bar}"
      "/{bar}

      /b/c"
      "/a/

      {var}/c"
      "/a/b/c"
      "/a/{var1}/{var2}"
      "/{var1}/d"
      "/b/{var2}"

      Some examples of BAD path specs:

      "/a/b{var}

      " - variable does not encompass whole path segment
      "a/

      {var}" - no start slash
      "/a/{var/b}" - path segment separator in variable name
      "/{var}

      /*" - no globs allowed
      "/

      {var}.do" - variable does not encompass whole path segment
      "/a/{var*}" - use of glob character not allowed in variable name.
      "/a/{}" - no variable name declared
      "/a/{---}" - no alpha character in variable name declared
      "{var}

      " - no start slash
      "/a/

      {my special variable}

      " - bad syntax for variable name, spaces used
      "/a/

      {var}/{var}

      " - duplicate variables (case sensitive)
      "/a/

      {var}/{Var}/{vAR}" - duplicate variables (case insensitive)
      "/a/../../{var}

      " - path navigation
      "/a/./

      {var}" - path navigation
      "/a//{var}

      " - empty path segment

      There are a number of things that could be better defined for valid path specs.
      Here's an example of some of the rules.

      1) Path Specs must start with "/" character
      2) A "path segment" is all characters between separators "/"
      3) A single path segment must be either a literal set of characters or a path param variable, but not both.
      4) A path segment cannot use the characters '

      {', '}

      ', '/', or '*'
      5) path navigation sequences "/../", "/./", and "//" cannot be used
      6) Variable names must conform to the established variable name syntax ( see WEBSOCKET_SPEC-193 )
      7) Duplicate variables names are not allowed to be present in path spec
      8) Variable names are case-insensitive

        Activity

        joakimerdfelt created issue -
        Hide
        markt_asf added a comment -

        I agree with rules 1, 2, 3, 4, 6, 7

        re rule 5: Need to decide how to handle //. Not sure about this yet.
        re rule 8: RFC6570 says variable names are case sensitive.

        note: RFC6570 is stricter than rule 4.

        Show
        markt_asf added a comment - I agree with rules 1, 2, 3, 4, 6, 7 re rule 5: Need to decide how to handle //. Not sure about this yet. re rule 8: RFC6570 says variable names are case sensitive. note: RFC6570 is stricter than rule 4.
        Hide
        dannycoward added a comment -

        This is a good list, but much of it is already covered in the spec.

        1. See ServerEndpointConfig.Builder.create() or ServerEndpoint.value()

        2, 3, 4, 6, 8 are definied in the URI spec and/or the URI-template spec (e.g. section 2)

        7) We should clarify in the spec (thankyou)

        On 5), my read of RFC2396 is that '//' is not a valid URI ? And that "/../.." is OK to use.

        Show
        dannycoward added a comment - This is a good list, but much of it is already covered in the spec. 1. See ServerEndpointConfig.Builder.create() or ServerEndpoint.value() 2, 3, 4, 6, 8 are definied in the URI spec and/or the URI-template spec (e.g. section 2) 7) We should clarify in the spec (thankyou) On 5), my read of RFC2396 is that '//' is not a valid URI ? And that "/../.." is OK to use.
        Hide
        joakimerdfelt added a comment -

        Since we are following RFC6570, then #8 (variable names are case-insensitive) isn't correct.

        Section 2.3 Variables
        http://tools.ietf.org/html/rfc6570#section-2.3

        Regarding the path navigation sequences...
        In servlet-3_0-mrel-spec.pdf section 14.2 - Rules for Processing the Deployment Descriptor
        The servlet container is expected to canonicalize paths while resolving the deployment descriptor, and also (in a later part of the spec) resolve paths before passing them onto the matching of paths to servlets.

        That has 2 parts to be concerned about.
        part 1) the @ServerEndpoint("/path") definition should be canonicalized by the implementation.

        This could prove problematic for RFC6570 variables using `pct-encoded` form, as the decoding process could decode things prior to working with the URI template.
        Eg: defined as "/path/../

        {%40hi}

        " - canonicalized to "/path/

        {@hi}

        " - now invalid per RFC6570 variable naming rules.
        Not an impossible scenario, but a good gotcha waiting for implementors.

        part 2) the incoming request should be resolved/canonicalized before attempting matching.
        Seems sensible, and its what all good servlet containers do already prior to servlet/filter matching. But our JSR doesn't mandate a servlet container, so it would be good to mention for implementors that this should be done.

        Show
        joakimerdfelt added a comment - Since we are following RFC6570, then #8 (variable names are case-insensitive) isn't correct. Section 2.3 Variables http://tools.ietf.org/html/rfc6570#section-2.3 Regarding the path navigation sequences... In servlet-3_0-mrel-spec.pdf section 14.2 - Rules for Processing the Deployment Descriptor The servlet container is expected to canonicalize paths while resolving the deployment descriptor, and also (in a later part of the spec) resolve paths before passing them onto the matching of paths to servlets. That has 2 parts to be concerned about. part 1) the @ServerEndpoint("/path") definition should be canonicalized by the implementation. This could prove problematic for RFC6570 variables using `pct-encoded` form, as the decoding process could decode things prior to working with the URI template. Eg: defined as "/path/../ {%40hi} " - canonicalized to "/path/ {@hi} " - now invalid per RFC6570 variable naming rules. Not an impossible scenario, but a good gotcha waiting for implementors. part 2) the incoming request should be resolved/canonicalized before attempting matching. Seems sensible, and its what all good servlet containers do already prior to servlet/filter matching. But our JSR doesn't mandate a servlet container, so it would be good to mention for implementors that this should be done.

          People

          • Assignee:
            Unassigned
            Reporter:
            joakimerdfelt
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: