dev@jersey.java.net

Re: feature bag in ResourceConfig and new options <was> Re: reducing double slash to a single slash (//->/) in http servlet request path info ? bug or feature ?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 01 Aug 2007 15:27:23 +0200

Hi Jakub,

Your patch looks like a good start. You have found all the relevant areas.

Some suggested changes:

- Refer to string constants using documented public static final
   variables which are part of the API.

- For the string constants use a naming convention, for example:

   com.sun.ws.rest.feature.<name>

- RedirectToCanonicalURI implies PreserveContSlashes. Perhaps we should
   have the following:

   Redirect
   If either the features NormalizeURI or CanonicalizeURIPath are true
   and the application of normalization and/or canonicalization to the
   request URI result in a new URI that is not equal to the request URI
   then temporarily redirect the client to the new URI.

   NormalizeURI
   Normalize the request URI as specified by URI.normalize().

   CanonicalizeURIPath
   Canonicalize the path of the request URI by removing contiguous
   '/' from the path.

(all default to true)


Jakub Podlesak wrote:
>> then we need to add relevant options to the APT tool and modify it to
>> generate the correct ResourceConfig code and modify the runtime accordingly.
>
> I suggest to have following options:
>
> -Anoredir :
> no redirects to canonical URIs at all (however are they computed)
> -Apreserveslashes :
> whenever a request is redirected and whatever method is used
> to compute the canonical URI, multiple slashes must be preserved
>

IMHO I think we should have the APT options correspond exactly to the
features:

   -Aredirect

   -AnormalizeURI

   -AcanonicalizeURIPath

that have the same defaults as the features, and support a boolean value
(from using Boolean.valueOf) the absence of which assumes true, for example:

   -Aredirect # value is true
   -Aredirect=false
   -Aredirect=true


You may want to consider creating a temporary branch and commit changes
to that (just in case you loose stuff locally), then when it is ready
merge with the trunk, and then delete the temp branch. IIRC this is a
common way of working with SVN.

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109