Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi ng

[xiaohu <en...@byobroadcast.com>]

+1

On Mon, 2003-08-04 at 15:11, Pill, Juergen wrote:
> Hello,
> 
> We want to suggest a sematical interface change within the WebDAV method
> implementation of the client API (org.apache.webdav.lib.methods.xxxMethod).
> 
> Currently some of those methods do url-encoding (with utf-8) some do not.
> The basis of those classes is the HttpClient which expects all URLs already
> encoded, e.g. does no extra URL encoding.
> 
> We suggest implementing the same behavior (no extra URL encoding) in the
> WebDAV API layer too.
> 
> Reasons:
> 
>     * consistency - if all the existing methods expect already encoded
>       paths, then users will expect it to work this way.
>     * preventing stupid bugs by users - imagine a case where a library
>       user does a HeadMethod request (already encoded), and then
>       discovers to their suprise that they cannot pass the exact same
>       URL to PropFindMethod, but must _decode_ the URL before passing it.
>     * import confusion - if you import the "GetMethod" from
>       webdavclient, rather than from httpclient, it is impossible to
>       tell except by looking back at your import statement whether the
>       URL should be encoded or not.  I've tripped over this one.
>     * full URLs vs. partial paths - With the 2.0 release of HttpClient,
>       it is possible to pass either a full URLto a XxxMethod
>       constructor, or to set the HostConfiguration on HttpClient and
>       pass a server relative path to the XxxxMethod constructor.  I
>       originally tripped over a problem because I was passing full URLs
>       to the PropFindMethod(), only to discover that
>       "http://localhost:8080/" was getting converted to
>       "http%3A//localhost%3A8080/" and then failing.
> 
> 
> Please vote:
> 
> Modify the WebDAV client API in a way that no additional encoding is taking
> place. The calling layer will (need to) do the necessary encoding.
>  [ ] +1.  I agree with the change.
>  [ ] +0.  I don't care.
>  [ ] -1.  I don't agree, because:
> 
> Best regards,
> 
> Juergen
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org