Hi Andy,
OK. So the consensus is lets turn it off by default, then lets see if
we can do this properly.
Thanks for sending those interesting ideas. I will digest them and
reply in more detail next week.
Paul.
On Feb 6, 2008, at 10:14 PM, 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
>
> 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.
>
> 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)
>
> 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).
>
> 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.
>
>
> 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
>