[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


 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



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

Generated at Wed May 27 03:15:46 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.