I agree that this is a tough nut to crack.
The more I looked at the problem the more I convinced myself that if standard HttpClient methods assume already encoded URLs in their constructors, then the webdavclient XxxxMethod extensions must also do the same thing. I see several reasons for this:
* 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.For the above reasons, I think the webdavclient XxxxMethod classes must pick option (2), which is to assume that the path passed to them is already encoded (your comment about UTF-8 would be spurious at this point - the URL must be properly formed and already in US-ASCII format, what it started out as and how it was encoded would be impossible to discern from the point of view of the XxxxMethod).
Rolling back the changes on Monday would be ok by me. I got a snapshot from a few days ago that I'm actively developing against (if others are encountering this problem, I recommend a CVS get on the date 7/29/2003).
As Ingo notes in his response email, the WebdavResource class does encode the paths for you, rather than assume they are already encoded. I tend to agree with Ingo that this seems to be the right approach. As I see it, the "resource" API should hide the encoding issues, and the "protocol" API shouldn't (and cannot).
-Eric.
Pill, Juergen wrote:
Hello Eric,
This implication was not obvious to me, sorry if I have created any
inconvenience. I am currently trying to get the I18N test suite up and running again (xml
test suite with t-processor). During those tests I noticed, that the URL is
not encoded any more during transport to the server.
The new HttpClient expects all URLs already encoded, it does no extra encoding. The WebDAV client API did the encoding as a service for the calling API, at least some time ago. To my understanding, I thought those were the patches applied to e.g. PutMethod described in the mentioned e-mails (the path received in the PutMethod constructor is now utf-8 encoded).
I think we should discuss our expectations about the xxxMethod classes:
1) Would those classes convert ALL urls to UTF-8 2) Would those classes convert NO urls to UTF-8 [this is the way HttpClient works] 3) Would some methods of those classes convert urls to UTF-8.
I will remove my changes. Would it create a big problem, if this is done on Monday (as I will be at my computer again only late today)?
Best regards
Juergen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
