On Tue, Apr 9, 2013 at 7:11 PM, Mark Thomas <mark_at_homeinbox.net> wrote:
> 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<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<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.)
>
>
Ah, wasn't aware of it.
Looks like Section 2.3. Variables has the details.
http://tools.ietf.org/html/rfc6570#section-2.3
Looks like it would allow for pct-encoded (Section
1.5<
http://tools.ietf.org/html/rfc6570#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}
I came up with a few more Bad Path Spec examples since I wrote that email.
"/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
These forms bring up a few questions.
Should we prevent path navigation segments? ("/../", "/./", and "//")
Should we prevent duplicate variables names in the path spec?
Should we treat all variables in a case insensitive way when checking for
duplicates?
- Joakim