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._-]*" ?
--
Joakim Erdfelt <joakim_at_intalio.com>
webtide.com <http://www.webtide.com/>
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org