jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Valid ServerEndpoint.value() path specs?

From: Mark Thomas <mark_at_homeinbox.net>
Date: Tue, 09 Apr 2013 22:11:04 -0400

On 09/04/2013 17:12, Joakim Erdfelt wrote:
> Just want to see if there is any consensus on what qualifies as a valid
> path spec on the ServerEndpoint.value().
>
> Some examples of what I perceive are _Good Path Param Specs_.
>
> Good Examples from PFD1.pdf:
>
> "/bookings/{guest-id}" - section 4.1.1 and 4.3
> "/rewards/{vip-level}" - section 4.3
> "/hello" - section 2.1.4
>
> Good Examples from mailing list:
>
> From: Danny Coward
> Subject: [jsr356-experts] Post PFD fixes
> Date: Mon, 11 Mar 2013 16:48:11 -0700
> http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-03/message/16
>
> "/a/b/"
> "/a/{foo}"
> "/{bar}"
> "/{bar}/b/c"
>
> From: Danny Coward
> Subject: [jsr356-experts] Closing the gaps in the URI matching specification
> Date: Mon, 18 Mar 2013 17:12:35 -0700
> http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-03/message/33
>
> "/a/{var}/c"
> "/a/b/c"
> "/a/{var1}/{var2}"
> "/{var1}/d"
> "/b/{var2}"
>
> _Examples of Bad Path Param spec_: (my test cases)
>
> 1. "/a/b{var}" - variable does not encompass whole path segment
> 2. "a/{var}" - no start slash
> 3. "/a/{var/b}" - path segment separator in variable name
> 4. "/{var}/*" - no globs allowed
> 5. "/{var}.do" - variable does not encompass whole path segment
> 6. "/a/{var*}" - use of glob character not allowed in variable name.
> 7. "/a/{}" - no variable name declared
> 8. "/a/{---}" - no alpha variable name declared
> 9. "{var}" - no start slash
>
> Some concerns:
> In test case #3, 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?
> In test case #6, it could also be allowed as a funky variable named
> "var*", again, this should probably be alerted to the user as bad form.
> And test case #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._-]*" ?

RFC 6570 already provides suitable limits for variable names doesn't it?
(And it is very close to what you propose above.)

Mark