On Sep 7, 2009, at 3:31 PM, Charles Brooking wrote:
> Paul Sandoz wrote:
>> > My understanding is that the current redirection happens whenever a
>> > request's path + "/" equals @Path for some resource. So perhaps
>> > the opposite could happen whenever request.getPath() equals some
>> > @Path + "/". Then no user declaration is necessary.
>>
>> The current behavior when ResourceConfig.FEATURE_REDIRECT is enabled
>> is to return a 404.
>>
>> What i am wondering is: should we should break that behavior to
>> redirect, or require that a another, new, feature to be set for such
>> redirection to occur?
>
> If there's no resource mapped to /foo/ and a client requests /foo,
> then a redirect should not hurt anything. It's just to help clients
> who can't get their slashes right - and we return a 307 which is
> only a temporary redirect.
>
> I reckon it's in keeping with the spirit of the current redirect
> feature; I expected that enabling
> com.sun.jersey.config.feature.Redirect would do this already and was
> surprised when it didn't.
>
I agree, it is just that i am concerned about backwards compatibility.
If we change the current behavior will it break any existing
deployments? i.e. clients that perviously consumed 404 will consume
307. Perhaps it is not a big deal, but i tend to err on being
conservative in this respect.
Paul.
> There could be a check in case both /foo and /foo/ are mapped, but
> this would also be an issue for the current redirect feature - and
> who in their right mind would do it anyway?
>
> Later
> Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>