[WEBSOCKET_SPEC-194] Clarify what is a valid WebSocket path spec syntax 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 would be a valid websocket path spec syntax?

Some examples of GOOD path specs:



" - section 4.1.1 and 4.3


" - section 4.3
"/hello" - section 2.1.4






Some examples of BAD path specs:


" - variable does not encompass whole path segment

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

/*" - 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

" - no start slash

{my special variable}

" - bad syntax for variable name, spaces used


" - duplicate variables (case sensitive)

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

" - path navigation

{var}" - path navigation

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

Comment by markt_asf [ 19/Apr/13 ]

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.

Comment by dannycoward [ 23/Apr/13 ]

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.

Comment by joakimerdfelt [ 23/Apr/13 ]

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

Section 2.3 Variables

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


" - canonicalized to "/path/


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

Generated at Tue Mar 28 01:45:10 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.