URL encoding
Hi, My webdav client (using slide) is trying to connect to a URL that is something like this: http://myhost.com/users/[EMAIL PROTECTED]/images The path being "/users/[EMAIL PROTECTED]/images" The '@' character is causing errors. Appearently, the webdav server does not like how it's encoded... but the client library converts this character into '%2540'... before the http request is sent. I sniffed the packets using ethereal, and discovered that using another webdav client the server accepts '@' encoded as '%40'. I tried to replace the '@' with '%40' in the path (hardcoded hack test), but then the slide client lib converts it into '%252540'. Seems like it's encoding the '%' character. Isn't there a way to control how the slide library encodes this? I noticed a deprecated setEncodeURLs(boolean) method in WebdavResource, I tried it but it did nothing. Summary: My error is: Got status code 409, on propfind using "/users/john%2540myhost.com/images" Needs to be: "/users/john%40myhost.com/images" -- Kveðjur Árni Arent [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
URL encoding patch, was Re: MKACTIVITY and transactions
That's fine as long as the problem gets solved. I'll test yours in my setup and report later. I just discovered an issue that breaks my fix. Something is different when using the AJP connector in Tomcat instead of the HTTP connector. We use mod_jk2 with the Apache webserver to integrate several applications together under a single site; we do the SSL on the webserver also. It seems that URLs are handled differently by the AJP connector or the webserver does something to the URLs before passing them to Tomcat; it breaks the UTF-8 detection logic. I'll check this. Carlos Thomas Draier wrote: hi, i just found your bug entry and it looks like it is exactly the same problem as the one i had - but the patch i submitted has not been commited .. i may do it when i'll get some karma :-) maybe you can try it (bug 31265), and tell me if it also fix your problem. i think both patch conflicts, even if they do not acts on the same class/methods, they seems to fix the same problem. i've tested with the same clients (netdrive, xp without office, and cadaver) but on a french os. sorry i did not see your bug entry before .. thomas Le 2 déc. 04, à 13:12, Oliver Zeigermann a écrit : Which one is it? I think Thomas is the one who has insight. Maybe he can help?! Thomas? Oliver On Thu, 02 Dec 2004 19:30:40 +0900, Carlos Villegas <[EMAIL PROTECTED]> wrote: No. I don't have any code. As you said it just sounded like a good idea... BTW, I submitted a patch sometime ago to fix url encoding on double byte locales. I haven't heard if a committer reviewed it and it has been accepted or rejected. I think somebody was asking recently about chinese. I only tested with japanese but I think it should work with chinese and korean as well. Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL Encoding and decoding is giving problem
What is the problem exactly? -James Koundinya (Sudhakar Chavali) wrote: I try to explain my scenario We are working with the exchange server related project using Slide When we send a message to destination user, Exchange Server maintains the message with the name of Subject for example if i give Subject as Test\ Hello It stores the message in Test_xF8FE_%20Hello.EML file So now encoding and decoding using URLEncoder/URLDecoder is giving problems in such cases = "No one can earn a million dollars honestly."- William Jennings Bryan (1860-1925) "Make everything as simple as possible, but not simpler."- Albert Einstein (1879-1955) "It is dangerous to be sincere unless you are also stupid."- George Bernard Shaw (1856-1950) ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
URL Encoding and decoding is giving problem
I try to explain my scenario We are working with the exchange server related project using Slide When we send a message to destination user, Exchange Server maintains the message with the name of Subject for example if i give Subject as Test\ Hello It stores the message in Test_xF8FE_%20Hello.EML file So now encoding and decoding using URLEncoder/URLDecoder is giving problems in such cases = "No one can earn a million dollars honestly."- William Jennings Bryan (1860-1925) "Make everything as simple as possible, but not simpler."- Albert Einstein (1879-1955) "It is dangerous to be sincere unless you are also stupid."- George Bernard Shaw (1856-1950) ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URL Encoding happening too often...
I compiled against the very latest CVS code at the time - it was early last week when I did my last CVS update. I also ran into the IllegalArgumentException as well as a few others. I made the modifications I described below which only got me to the next exception. Since my compelling reason for going to the new code was to get the updated Interceptor API, I found it easier to just back-port the newer version of the API into the working 1.0.16 code base. If anyone is interested in the patches to upgrade 1.0.16 to the same Interceptor API as appears in the 2.0.0 release, please let me know and I'll post it. In particular I needed to know when documents had been removed so I could keep a lucene search index in sync with the documents. This was the key missing part of the 1.0.16 Interceptor API. Brian -Original Message- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 2:18 AM To: [EMAIL PROTECTED] Subject: Re: URL Encoding happening too often... Hi Brian, are you using the latest cvs code? My attempt to try this out, revealed another problem. Commons-httpclient was changed not long ago to take already escaped paths in the HttpMethodBase constructor. But Slide does not do the encoding at this point. So I get an IllegalArgumentException on a call to a method from within WebdavResource if the path contains spaces. Regards, Ingo > I have a client tool I've developed against slide 1.0.16 which has been > working well for quite a while now. I needed to integrate Lucene based > search into my project and found that slide 2.0.0 (cvs head) had an > Interceptor API which I could easily leverage for my needs. Here's the > problem: > > =20 > > I am having trouble with the 2.0.0 release in that any files which = > result in > a different URI when URLEncoded result in 404 errors from the slide = > server. > I can perform uploads (PUT) without any issues, but when I do a PROPFIND = > for > example, a 404 results. The problem seems to be in the > commons-httpclient.jar provided with slide in the cvs tree. Using the > TcpTunnelGui provided in the apache soap project, I am able to monitor = > the > traffic between my client (using commons-httpclient.jar) and the slide > server to isolate the problem. In case anyone isn't familiar with this = > tool, > it's very handy and I suggest you check it out. > > =20 > > C:\devapps\soap-2_3_1\lib>java -cp soap.jar > org.apache.soap.util.net.TcpTunnelGui 8081 localhost 8080 > > =20 > > What seems to be happening is that the commons-httpclient.jar is = > performing > the URL encoding twice for some, but not all methods. The sample file I = > am > using has a space in the filename. "Junk File.txt". It appears correctly = > in > the property store and object tables after an upload completes, but when = > I > do a webdavResource.propfindMethod(.) it fails. The request generated by > httpclient converts the filename into "Junk%2520File.txt" instead of the > proper "Junk%20File.txt". Here's how that's happening: > > =20 > > "Junk File.txt" --> (encoded once) "Junk%20File.txt" --> (encoded again) > "Junk%2520File.txt" > > =20 > > I have tracked down where these encoding operations are happening and = > would > appreciate some guidance from any of those of you more versed in the = > APIs on > how to properly fix this without breaking other things. > > =20 > > The first encoding seems to be happening in the setPath() methods of the > following classes: > > org.apache.webdav.lib.methods.GetMethod > > org.apache.webdav.lib.methods.HeadMethod > > org.apache.webdav.lib.methods.HttpRequestBodyMethodBase *** > > org.apache.webdav.lib.methods.MkcolMethod > > org.apache.webdav.lib.methods.PutMethod > > org.apache.webdav.lib.methods.UnlockMethod > > =20 > > There are several more classes derived from HttpRequestBodyMethodBase = > which > have the problem based on their extension of a base class with the = > problem: > > org.apache.webdav.lib.methods.AclMethod > > org.apache.webdav.lib.methods.AclReportMethod > > . and on and on . > > =20 > > The setPath methods in each of these looks something like this: > > /** > > * Set the path part of my request. > > * It is responsibility of the caller to ensure that the path is > > * properly encoded (URL safe). > > * > > * @param path the path to request. The path is expected > > *to be NOT URL-encoded > > * @param enc the encoding used to encode the path. UTF-8 is the > default. > > */ > >
URL Encoding happening too often...
I have a client tool I've developed against slide 1.0.16 which has been
working well for quite a while now. I needed to integrate Lucene based
search into my project and found that slide 2.0.0 (cvs head) had an
Interceptor API which I could easily leverage for my needs. Here's the
problem:
I am having trouble with the 2.0.0 release in that any files which result in
a different URI when URLEncoded result in 404 errors from the slide server.
I can perform uploads (PUT) without any issues, but when I do a PROPFIND for
example, a 404 results. The problem seems to be in the
commons-httpclient.jar provided with slide in the cvs tree. Using the
TcpTunnelGui provided in the apache soap project, I am able to monitor the
traffic between my client (using commons-httpclient.jar) and the slide
server to isolate the problem. In case anyone isn't familiar with this tool,
it's very handy and I suggest you check it out.
C:\devapps\soap-2_3_1\lib>java -cp soap.jar
org.apache.soap.util.net.TcpTunnelGui 8081 localhost 8080
What seems to be happening is that the commons-httpclient.jar is performing
the URL encoding twice for some, but not all methods. The sample file I am
using has a space in the filename. "Junk File.txt". It appears correctly in
the property store and object tables after an upload completes, but when I
do a webdavResource.propfindMethod(.) it fails. The request generated by
httpclient converts the filename into "Junk%2520File.txt" instead of the
proper "Junk%20File.txt". Here's how that's happening:
"Junk File.txt" --> (encoded once) "Junk%20File.txt" --> (encoded again)
"Junk%2520File.txt"
I have tracked down where these encoding operations are happening and would
appreciate some guidance from any of those of you more versed in the APIs on
how to properly fix this without breaking other things.
The first encoding seems to be happening in the setPath() methods of the
following classes:
org.apache.webdav.lib.methods.GetMethod
org.apache.webdav.lib.methods.HeadMethod
org.apache.webdav.lib.methods.HttpRequestBodyMethodBase ***
org.apache.webdav.lib.methods.MkcolMethod
org.apache.webdav.lib.methods.PutMethod
org.apache.webdav.lib.methods.UnlockMethod
There are several more classes derived from HttpRequestBodyMethodBase which
have the problem based on their extension of a base class with the problem:
org.apache.webdav.lib.methods.AclMethod
org.apache.webdav.lib.methods.AclReportMethod
. and on and on .
The setPath methods in each of these looks something like this:
/**
* Set the path part of my request.
* It is responsibility of the caller to ensure that the path is
* properly encoded (URL safe).
*
* @param path the path to request. The path is expected
*to be NOT URL-encoded
* @param enc the encoding used to encode the path. UTF-8 is the
default.
*/
public void setPath(String path, String enc ) {
if (enc == null) enc = "UTF-8";
super.setPath(URLUtil.URLEncode(path, enc));
}
I have highlighted in RED an apparent disagreement in the documentation on
whether the paths should or should not be encoded at this point. It seems to
me that this should NOT be encoded based on the implementation of the
following method, which ALL these methods eventually use.
HttpMethodBase.generateRequestLine() line 1519
path = (requestPath == null) ? "/" :
URIUtil.encodePath(requestPath);
What is happening here is that the method-specific setPath for most methods
are doing encoding once and it's happening again just before the outgoing
request is generated.
I believe the fix is to remove the URLUtil.URLEncode(path, enc) from each of
the setPath() methods in which it appears. I am going to try this out now
and if it works, I'll submit some patches if it does. In the mean time if
you know that this will break other things, or you know how to fix this
another way, please let me know.
Thanks.
Brian Johnson
Re: URL Encoding happening too often...
Hi Brian,
are you using the latest cvs code?
My attempt to try this out, revealed another
problem. Commons-httpclient was changed not long ago to take already
escaped paths in the HttpMethodBase constructor. But Slide does not do
the encoding at this point. So I get an IllegalArgumentException on a
call to a method from within WebdavResource if the path contains
spaces.
Regards,
Ingo
> I have a client tool I've developed against slide 1.0.16 which has been
> working well for quite a while now. I needed to integrate Lucene based
> search into my project and found that slide 2.0.0 (cvs head) had an
> Interceptor API which I could easily leverage for my needs. Here's the
> problem:
>
> =20
>
> I am having trouble with the 2.0.0 release in that any files which =
> result in
> a different URI when URLEncoded result in 404 errors from the slide =
> server.
> I can perform uploads (PUT) without any issues, but when I do a PROPFIND =
> for
> example, a 404 results. The problem seems to be in the
> commons-httpclient.jar provided with slide in the cvs tree. Using the
> TcpTunnelGui provided in the apache soap project, I am able to monitor =
> the
> traffic between my client (using commons-httpclient.jar) and the slide
> server to isolate the problem. In case anyone isn't familiar with this =
> tool,
> it's very handy and I suggest you check it out.
>
> =20
>
> C:\devapps\soap-2_3_1\lib>java -cp soap.jar
> org.apache.soap.util.net.TcpTunnelGui 8081 localhost 8080
>
> =20
>
> What seems to be happening is that the commons-httpclient.jar is =
> performing
> the URL encoding twice for some, but not all methods. The sample file I =
> am
> using has a space in the filename. "Junk File.txt". It appears correctly =
> in
> the property store and object tables after an upload completes, but when =
> I
> do a webdavResource.propfindMethod(.) it fails. The request generated by
> httpclient converts the filename into "Junk%2520File.txt" instead of the
> proper "Junk%20File.txt". Here's how that's happening:
>
> =20
>
> "Junk File.txt" --> (encoded once) "Junk%20File.txt" --> (encoded again)
> "Junk%2520File.txt"
>
> =20
>
> I have tracked down where these encoding operations are happening and =
> would
> appreciate some guidance from any of those of you more versed in the =
> APIs on
> how to properly fix this without breaking other things.
>
> =20
>
> The first encoding seems to be happening in the setPath() methods of the
> following classes:
>
> org.apache.webdav.lib.methods.GetMethod
>
> org.apache.webdav.lib.methods.HeadMethod
>
> org.apache.webdav.lib.methods.HttpRequestBodyMethodBase ***
>
> org.apache.webdav.lib.methods.MkcolMethod
>
> org.apache.webdav.lib.methods.PutMethod
>
> org.apache.webdav.lib.methods.UnlockMethod
>
> =20
>
> There are several more classes derived from HttpRequestBodyMethodBase =
> which
> have the problem based on their extension of a base class with the =
> problem:
>
> org.apache.webdav.lib.methods.AclMethod
>
> org.apache.webdav.lib.methods.AclReportMethod
>
> . and on and on .
>
> =20
>
> The setPath methods in each of these looks something like this:
>
> /**
>
> * Set the path part of my request.
>
> * It is responsibility of the caller to ensure that the path is
>
> * properly encoded (URL safe).
>
> *
>
> * @param path the path to request. The path is expected
>
> *to be NOT URL-encoded
>
> * @param enc the encoding used to encode the path. UTF-8 is the
> default.
>
> */
>
> public void setPath(String path, String enc ) {
>
> if (enc =3D=3D null) enc =3D "UTF-8";
>
> super.setPath(URLUtil.URLEncode(path, enc));
>
> }
>
> =20
>
> I have highlighted in RED an apparent disagreement in the documentation =
> on
> whether the paths should or should not be encoded at this point. It =
> seems to
> me that this should NOT be encoded based on the implementation of the
> following method, which ALL these methods eventually use.
>
> =20
>
> HttpMethodBase.generateRequestLine() line 1519
>
> path =3D (requestPath =3D=3D null) ? "/" :
> URIUtil.encodePath(requestPath);
>
> =20
>
> What is happening here is that the method-specific setPath for most =
> methods
> are doing encoding once and it's happening again just before the =
> outgoing
> request is generated.
>
> =20
>
> I believe the fix is to remove the URLUtil.URLEncode(path, enc) from =
> each of
> the setPath() methods in which it appears. I am going to try this out =
> now
> and if it works, I'll submit some patches if it does. In the mean time =
> if
> you know that this will break other things, or you know how to fix this
> another way, please let me know.
>
> =20
>
> Thanks.
>
> =20
>
> Brian Johnson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
