I think the best way to specify the ignoring of matrix parameters is
to explicitly add it to the preprocessing of section 3.7.1. That way
its clear that any matrix parameters in the request URI are stripped
out for the purposes of matching to resource classes.
Marc.
On Nov 30, 2008, at 4:30 PM, Sergey Beryozkin wrote:
> Hi,
>
> > >> @GET
> > >> @Path("base/{tail}")
>
>
> > >> GET /base;matrixParam=ParamValue/beginTail
> > >>
> > >> does not match the method.
> > >The method matches the request, because the matching of
> @Path(...) ignores the matrix parameters.
>
>
> I have one more question about it. Consider a custom regular
> expression where a use explicitly requests that only URI containing no
> “;” symbols in a ‘/base’ path segment are accepted.
>
> I think it’s a very realistic way to enforcing a position of an
> expected matrix parameter while using @MatrixParam.
>
> Therefore I don’t think the algorithm ‘matching of @Path(...)
> ignores the matrix parameters’ works in all cases as it’s
> unrealistic IMHO to expect
> the runtime to check if an arbitrary regular expression explicitly
> disaalows ‘;’ or not as there’s a number of way to express this
> requirement in a regular
> expression.
>
> Thus I think we have :
>
> • @Path("base/{tail}")
> GET /base;matrixParam=ParamValue/beginTail
>
> This request should be matched
>
> • @Path("base/{tail}")
> GET /base/beginTail;matrixParam=ParamValue
>
> This request should be matched – this is the most
> expected outcome as we’re dealing with a default regular expression
>
> • @Path("{base:base&&[^;]}/{tail}")
> GET /base;matrixParam=ParamValue/beginTail
>
> This must not match – a user has explicitly requested it
> should not.
>
> • @Path("{base:base}/{tail}")
> GET /base;matrixParam=ParamValue/beginTail
>
> This should not match – how the runtime will find out
> that this arbitrary reg expression is not equivalent to that one in
> 3 ?.
>
> In fact, I believe 4 is identical to 1
>
>
> IMHO it would be inconsistent if 3 & 4 did not match but 1 were
> expected to match (as it is now).
>
> Thus I’d suggest that the algorithm “‘matching of @Path(...) ignores
> the matrix parameters’” is changed to
> “‘matching of @Path(...) ignores the matrix parameters’ only when
> parameterized path values are used as in {base}”.
>
> In cases like
> @Path("base/{tail}")
> GET /base;matrixParam=ParamValue/beginTail
>
> By default there should be no match – but if the user would like a
> match to happen while ensuring that ‘base’ path segment is used then
> it would be possible for a user to express it using an arbitrary
> regular expression which would expect ‘base’ plus optional matrix
> params.
>
>
> Any comments from experts ?
>
> Thanks, Sergey
>
>
>
>
>
>
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.