On 11/04/2013 19:09, Joakim Erdfelt 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.
Agreed. My current view is that this match should fail.
> 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.
D is certainly the better match. I'm still leaning to requiring all path
segments to have length > 0 (assuming application developers would find
that acceptable) that would mean this example matches neither.
Mark