jsr356-experts@websocket-spec.java.net

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

From: Joakim Erdfelt <joakim_at_intalio.com>
Date: Thu, 18 Apr 2013 15:24:40 -0700

I've opened the following bugs from content in this thread.

http://java.net/jira/browse/WEBSOCKET_SPEC-193 - Clarify what is a valid
WebSocket path spec variable name
http://java.net/jira/browse/WEBSOCKET_SPEC-194 - Clarify what is a valid
WebSocket path spec syntax
http://java.net/jira/browse/WEBSOCKET_SPEC-195 - Clarify path param (URI
template) matching behavior of trailing '/' in incoming path


--
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
On Thu, Apr 11, 2013 at 11:09 AM, Joakim Erdfelt <joakim_at_intalio.com> wrote:
> Another fishing for opinion ...
>
> In the email
> http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-03/message/33
> From: Danny Coward
> Subject: Closing the gaps in the URI matching specification
> Date: Mon, 18 Mar 2013 17:12:35 -0700
>
> He gives a particular example ...
>
> suppose we have three endpoints and their paths:
> endpoint A: /a/{var}/c
> endpoint B: /a/b/c
> endpoint C: /a/{var1}/{var2}
> incoming URI: a/b/c matches B, not A or C, because an exact match is
> preferred.
> incoming URI: a/d/c matches A with variable var=d, because like goldlocks,
> its just right :)
> incoming URI: a/x/y/ matches C, with var1=x, var2=y
>
> I have issue with In the last match of incoming path "a/x/y/" (note the
> trailing slash)
> I feel this is a bad behavior of the matching.
>
> A scenario to ponder this behavioral quirk.
>
> endpoint A: "/a/{var}/c/"
> endpoint B: "/a/b/c"
> endpoint C: "/a/{var1}/{var2}"
> endpoint D: "/a/{var1}/{var2}/{var3}"
>
> What should the incoming path "/a/x/y/" match?
> Is it endpoint C with ...
>    var1 = "x"
>    var2 = "y"
> or is it endpoint D with ...
>    var1 = "x"
>    var2 = "y"
>    var3 = ""
>
> I don't think it should match C as the incoming path has the trailing
> slash indicating another path segment.
> Since we are calling this whole concept PathParam, I feel that this would
> keep us consistent as well.
>
>
>
> --
> 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
>
>
> On Wed, Apr 10, 2013 at 6:27 PM, Mark Thomas <mark_at_homeinbox.net> wrote:
>
>> On 10/04/2013 00:48, Joakim Erdfelt wrote:
>>
>>  These forms bring up a few questions.
>>>
>> My $0.02
>>
>>
>>  Should we prevent path navigation segments? ("/../", "/./", and "//")
>>>
>> Yes
>>
>>
>>  Should we prevent duplicate variables names in the path spec?
>>>
>> Yes
>>
>>
>>  Should we treat all variables in a case insensitive way when checking
>>> for duplicates?
>>>
>> No.
>>
>> Mark
>>
>
>