websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-193

Clarify what is a valid WebSocket path spec variable name

    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 makes up a valid websocket path spec variable name?

      Some examples of bad path specs with variable names present:

      1) "/a/

      {var/b}

      " - path segment separator in variable name
      2) "/a/

      {var*}

      " - use of glob character not allowed in variable name.
      3) "/a/{}" - no variable name declared
      4) "/a/{---}" - no alpha variable name declared
      5) "/a/

      {my special variable}

      " - spaces not allowed

      Example #1, it could be allowed as a funky variable named "var/b", but is this something we should alert the user of as a possible typo?

      Example #2, it could also be allowed as a funky variable named "var*", again, this should probably be alerted to the user as bad form.

      Example #3 has no variable name, it should just be forbidden

      Example #8, it could also be a funky variable named "---".

      Should we restrict the allowable variable names to conform to some sort of limited scope of characters? Say regex "[a-zA-Z0-9._-]*" ?

      It was brought up that RFC 6570 already provides some suitable limits for variable names.

      Looks like Section 2.3. Variables has the details.
      http://tools.ietf.org/html/rfc6570#section-2.3

      Looks like it would allow for pct-encoded (Section 1.5) in varname.
      Sounds reasonable.

      To translate what I see.
      varchar = (ALPHA / DIGIT / "_" / pct-encoded)
      varname = varchar *( ["."] varchar)

      So that would make the following Good Variable names.

      {a} {ab} {a.b} {a_b} {alpha.beta} {Answer_42}

      {_}

      {1_000_000} {%40ClientEndpoint}

      and the following would be Bad Variable names.

      {a b} {a..b} {alpha } { beta} {1,000,000}

      The direction of RFC 6570 seems like a good start, but some of the things it seems to allow might complicate things.

        Activity

        No work has yet been logged on this issue.

          People

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

            Dates

            • Created:
              Updated: