jsr356-experts@websocket-spec.java.net

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

From: Joakim Erdfelt <joakim_at_intalio.com>
Date: Thu, 11 Apr 2013 11:09:50 -0700

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
>