Hi,
I have modified things so that URI normalization, URI path
canonicalization and redirection are by default turned off. See the
ResourceConfig javadoc for more details on these features. To enable a
feature in Servlet add an init-param whose name corresponds to the
feature name and whose value is "true". To enable a feature in the LW
HTTP server or Grizlly instantiate an implementation of ResourceConfig
and set the feature to true.
Andy Bailey wrote:
> The problem with the automatic redirection is shown the bug I filed
> there is a "{path}" and a "{path}/" and its not like in a regular web
> server where you can just look at the resource on the filesystem and if
> its a directory redirect adding a trailing /.
>
> Idea 1:
> algoritmn something like:
>
> if a URI matches several @Paths use the longest one
> if a one @Path exists that matches the request URI use it
> else if request URI does not end in a / and a @Path exists that matches
> the request URI+"/" do a redirect to that URL
> else return 404
>
> Thoughts: Not sure if it works
>
That was almost the previous default behaviour, expect it did not do the
first bit (which is a bug, namely to check if there is an explicit
application-defined path that ends in a slash).
I also recommend reading the JSR-311 specification [1], section 2.5 on
matching requests to resource methods. (Note that the redirection
behaviour is a Jersey feature not a JAX-RS feature).
> Idea 2:
> Path regular expressions: @Path("xyz/?",regexp=true)
> if a reqest comes in for xyz redirect to xyz/
> if a request comes in for xyz/ handle it
> (its not cache friendly having 2 URLs for the same resource)
>
> Thoughts: Regular expression syntax could be interesting but shouldnt be
> the default.
>
That is how i implemented it :-) i transform the path values to regular
expressions (see section 2.5.1) so that a path of "xyz" or "xyz/" is
transformed to the regex "xyz(/)?"
> Idea 3
> Extra attribute in path
> @Path(value="xyz",directory=true)
> if a reqest comes in for xyz redirect to xyz/
> if a request comes in for xyz/ handle it
>
> Thoughts: Fairly simple and understandable (I think)
>
Agreed, although i would prefer not to have more attributes on Path, and
would prefer something in the text of path itself.
> Idea 4:
> I saw talk of a @Location annotation although I think the name
> @Redirect would be more understandable.
>
> @Path("xyz")
> @Redirect("xyz/")
> public void redirectXyz()
> {
> }
> Note: void methods make sense in this case.
>
> Thoughts: could have too many methods that only do redirects (see next
> idea for a possible solution to this).
>
You can do that using response builder and URI builder:
@Path("xyz")
public void redirectXyz(@HttpContext UriInfo uriInfo) {
return Response.temporaryRedirect(
uriInfo.getRequestUriBuilder().path("/").build()).build();
}
> Idea 5:
> Implement filters before the request and allow the developer to decide
> @PreFilter
> public Response preFilter(...)
> {
> Response response=null;
> //if the response is null carry on with the request
> //if not halt the request processing and generate the response for the
> client
> return response;
> }
>
> This is really another idea but since Im on the subject of filters how
> about:
> @PostFilter
> public void closeSession()
> {
> //Tidy up
> //see the Open Session in View pattern for Hibernate for the reasons
> for this.
> }
>
>
> To keep it really simple my votes are for no automatic redirection, and
> I like the idea of the filters.
>
Yes, i have been wondering about filters too. When using the per-request
life-cycle a constructor can be considered a pre filter where a
WebApplicationException can be thrown. But that does not work for the
singleton life-cycle. Not is there a concept of a post filter.
I suspect utilizing an IoC framework like Spring may be able to help
rather than defining something specific in Jersey e.g. using method
interceptors.
Paul.
[1]
https://jsr311.dev.java.net/drafts/spec20080131.pdf
>
> Andy Bailey
>
> On Wed, 2008-02-06 at 10:42 +0100, Paul Sandoz wrote:
>> Hi,
>>
>> Jersey attempts to support automatic redirection by default. But there
>> are some problems highlighted here [1]. The redirection implementation
>> is a little buggy but also it can cause some surprises for people when
>> it is working correctly (for example when using 'curl' without the -L
>> option).
>>
>> This makes me think that by default this functionality should be
>> switched off. What do others think?
>>
>> Paul.
>>
>> [1]
>> https://jersey.dev.java.net/servlets/BrowseList?list=users&by=thread&from=1028195
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=38
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109