On Dec 2, 2008, at 11:47 AM, Sergey Beryozkin wrote:
>
> I have some questions about section 3.7.3 of the specifications and
> the JavaDocs of the @Path annotation. I'm sorry if these questions
> are offtopic really...
>
> 1. Section 3.7.3/1 says "URI encode the template, ignoring URI
> template variable specifications"
>
> I don't quite understand it. For ex :
>
> @Path ("{bar:barfoo}")
>
> Which part of this value needs to be URI encoded and when failing to
> do so will produce unexpected results ?
> There could be requests with URL-encoded URIs but I'm not sure why
> say we can't do
>
> @Path ("{bar:bar%20foo}")
>
> if we were to handle URIs like /bar%20foo ?
>
See the javadoc for @Path. Literal chars in the template will be
encoded but not those within a regex. So, @Path("{bar:bar foo}") will
never match since matching is performed in encoded space and the " "
in the regex will not be encoded by the runtime. @Path("{bar:bar
%20foo}") would be required in that case.
> 2. Section 3.7.3/2 says "Escape any regular expression characters in
> the URI template, again ignoring URI template variable specifications"
>
> Would it be possible to explain when it's needed ? I've implemented
> 3.7.3/3-3.7.3/5 bits and I'm not sure why I'd need to do the
> additional escaping - as a user would escape all the built-in
> regular expression characters anyway when specifying a Path's value
>
E.g. if the URI template contains a literal '.' then you have to
escape it so it represents a literal . in the resulting regex and not
the regex character class that represents any char. E.g. @Path("a.b")
converted to a regex using 3.7.3 is "a\.b(.*)?" since you have to
escape the '.'.
> 3. @Path JavaDocs allows for WSP (whitespace characters ?) before/
> after a template variable name and a custom regular expression.
> Something like this probably :
>
> @Path ("{ bar : barfoo }")
> I'm assuming that ' bar ' and ' barfoo ' obtained after handling
> this value will need to be String.trim()-ed, is it correct
>
Correct.
> 4. Section 3.7.2.2.f says among other things :
>
> sort using the number of capturing groups as a secondary key
> (descending order)
> sort using the number of capturing groups with non-default regular
> expressions as the tertiary key (descending order)
>
> Question : 'the number of capturing groups' - is it the total one,
> including those with with non-default regular expressions ?
>
Yes, includes all capturing groups, default or specific. Another way
of saying it would be "number of template parameters".
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.