[WEBSOCKET_SPEC-193] Clarify what is a valid WebSocket path spec variable name Created: 18/Apr/13  Updated: 23/Apr/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: joakimerdfelt Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


As brought up in jsr356-experts:

What makes up a valid websocket path spec variable name?

Some examples of bad path specs with variable names present:

1) "/a/


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


" - 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.

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.

Comment by markt_asf [ 19/Apr/13 ]

The limits from RFC6570 seem reasonable to me. Which ones do you think could be problematic?

Comment by dannycoward [ 23/Apr/13 ]

Hey there,

We are using level-1 templates only (e.g. see the spec document section 4.1.1). RFC6570 makes an unambiguous definition of what the legal characters are there.

Let me know if there are any ambiguities in the RFC6570 definition - Danny

Comment by joakimerdfelt [ 23/Apr/13 ]

RFC6570 has only 1 ambiguous part with how it relates to our JSR.

Section 2.3 - Variables

variable-list = varspec *( "," varspec )
varspec = varname [ modifier-level4 ]
varname = varchar *( ["."] varchar )
varchar = ALPHA / DIGIT / "_" / pct-encoded

So that means, to the JSR, that @ServerEndpoint("/fruit/%40Type") would be allowed.
(My reading of level-1 variable names would be what 'varname' is defined like above)
However, when the @PathParam matching it up to the variable is concerned, do we follow the same 'varname' syntax as well? (this is not specified in section 4.3 of our JSR)
The declaration could be either @PathParam("%40Type") (leaving 'pct-encoded' alone)
or @PathParam("@Type") (decoded form of the pct-encoded)

Generated at Wed Jan 18 19:30:58 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.