You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by "Pill, Juergen" <Ju...@softwareag.com> on 2003/08/04 09:11:34 UTC
[VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
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
RE: bad request exception for grant permission
Posted by Haiying Qiao <qi...@ait.nrl.navy.mil>.
Thanks! I found that I also have to grant /history to the user, otherwise
the user still can't upload a file. This may cause authorization problem. Is
there any way to get arround of this?
Regards,
Haiying Qiao
-----Original Message-----
From: Ingo Brunberg [mailto:ib@fiz-chemie.de]
Sent: Thursday, August 07, 2003 2:40 AM
To: slide-user@jakarta.apache.org
Subject: Re: bad request exception for grant permission
Just name the permission, not the object node. Therefore you should
try:
grant write on /slide/files to guest
Regards,
Ingo
> I am using 7/30 build and deployed in Tomcat 4.1
> Login as root, issue grant command as:
>
> grant /actions/write on /slide/files to guest
>
> get Bad Request (400) from client console.
>
> The server side shows: Error parsing requestBody: ........
>
>
> Is this a bug or I did something wrong? Any helps are appreciated.
>
> Haiying Qiao
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
RE: bad request exception for grant permission
Posted by Haiying Qiao <qi...@ait.nrl.navy.mil>.
Thanks! I found that I also have to grant /history to the user, otherwise
the user still can't upload a file. This may cause authorization problem. Is
there any way to get arround of this?
Regards,
Haiying Qiao
-----Original Message-----
From: Ingo Brunberg [mailto:ib@fiz-chemie.de]
Sent: Thursday, August 07, 2003 2:40 AM
To: slide-user@jakarta.apache.org
Subject: Re: bad request exception for grant permission
Just name the permission, not the object node. Therefore you should
try:
grant write on /slide/files to guest
Regards,
Ingo
> I am using 7/30 build and deployed in Tomcat 4.1
> Login as root, issue grant command as:
>
> grant /actions/write on /slide/files to guest
>
> get Bad Request (400) from client console.
>
> The server side shows: Error parsing requestBody: ........
>
>
> Is this a bug or I did something wrong? Any helps are appreciated.
>
> Haiying Qiao
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: bad request exception for grant permission
Posted by Ingo Brunberg <ib...@fiz-chemie.de>.
Just name the permission, not the object node. Therefore you should
try:
grant write on /slide/files to guest
Regards,
Ingo
> I am using 7/30 build and deployed in Tomcat 4.1
> Login as root, issue grant command as:
>
> grant /actions/write on /slide/files to guest
>
> get Bad Request (400) from client console.
>
> The server side shows: Error parsing requestBody: ........
>
>
> Is this a bug or I did something wrong? Any helps are appreciated.
>
> Haiying Qiao
Re: bad request exception for grant permission
Posted by Ingo Brunberg <ib...@fiz-chemie.de>.
Just name the permission, not the object node. Therefore you should
try:
grant write on /slide/files to guest
Regards,
Ingo
> I am using 7/30 build and deployed in Tomcat 4.1
> Login as root, issue grant command as:
>
> grant /actions/write on /slide/files to guest
>
> get Bad Request (400) from client console.
>
> The server side shows: Error parsing requestBody: ........
>
>
> Is this a bug or I did something wrong? Any helps are appreciated.
>
> Haiying Qiao
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
bad request exception for grant permission
Posted by Haiying Qiao <qi...@ait.nrl.navy.mil>.
I am using 7/30 build and deployed in Tomcat 4.1
Login as root, issue grant command as:
grant /actions/write on /slide/files to guest
get Bad Request (400) from client console.
The server side shows: Error parsing requestBody: ........
Is this a bug or I did something wrong? Any helps are appreciated.
Haiying Qiao
bad request exception for grant permission
Posted by Haiying Qiao <qi...@ait.nrl.navy.mil>.
I am using 7/30 build and deployed in Tomcat 4.1
Login as root, issue grant command as:
grant /actions/write on /slide/files to guest
get Bad Request (400) from client console.
The server side shows: Error parsing requestBody: ........
Is this a bug or I did something wrong? Any helps are appreciated.
Haiying Qiao
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: How can we add users?
Posted by Julian <ce...@yahoo.com>.
Aruna,
If you are using the SlideRealm for authentication,
then you need to edit the Domain.xml. Although I am
unsure if this runs in weblogic, but I would consult
your servlet container's spec on how the
authentication is done. Any else know about this? I
currently use a Tomcat Realm and it seems to work
fine.
As far as the syntax for Domain.xml try this:
http://jakarta.apache.org/slide/conf-lib.html
I am unsure if there are any tools in the web-based
admin interface to add users.
HTH,
Julian
--- Aruna Goli <ar...@covigna.com> wrote:
> Hello
>
> I got slide to deploy on weblogic and when I start
> up the server and
> go to the first page
>
> http://localhost:7001/slide I am able to view a
> listing of the files but
> I cannot perform any actions.
>
> How do I add the users to the system, similar to
> tomcat-users.xml
>
> Thanks
> Aruna
>
> This is what I get on my console
>
>
> [exec] 04 Aug 2003 16:53:07 - WARNING -
> WARNING: No active
> transaction
> [exec] 04 Aug 2003 16:53:07 -
> org.apache.slide.common.Domain -
> WARNING - Ac
> cess denied on /users by user /users/guest for
> action /actions/read
> [exec] 04 Aug 2003 16:53:07 -
> org.apache.slide.common.Domain -
> WARNING - Ac
> cess denied on /actions by user /users/guest for
> action /actions/read
> [exec] 04 Aug 2003 16:53:07 - WARNING -
> WARNING: No active
> transaction
> [exec] 04 Aug 2003 16:53:07 -
> org.apache.slide.webdav.WebdavServlet
> - INFO
> - GET = 200 OK (time: 110 ms) URI = /
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> slide-user-help@jakarta.apache.org
>
=====
Live simply so others may simply live.
�
-Ghandi
�
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
�
-William of Occam
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: How can we add users?
Posted by Julian <ce...@yahoo.com>.
Aruna,
If you are using the SlideRealm for authentication,
then you need to edit the Domain.xml. Although I am
unsure if this runs in weblogic, but I would consult
your servlet container's spec on how the
authentication is done. Any else know about this? I
currently use a Tomcat Realm and it seems to work
fine.
As far as the syntax for Domain.xml try this:
http://jakarta.apache.org/slide/conf-lib.html
I am unsure if there are any tools in the web-based
admin interface to add users.
HTH,
Julian
--- Aruna Goli <ar...@covigna.com> wrote:
> Hello
>
> I got slide to deploy on weblogic and when I start
> up the server and
> go to the first page
>
> http://localhost:7001/slide I am able to view a
> listing of the files but
> I cannot perform any actions.
>
> How do I add the users to the system, similar to
> tomcat-users.xml
>
> Thanks
> Aruna
>
> This is what I get on my console
>
>
> [exec] 04 Aug 2003 16:53:07 - WARNING -
> WARNING: No active
> transaction
> [exec] 04 Aug 2003 16:53:07 -
> org.apache.slide.common.Domain -
> WARNING - Ac
> cess denied on /users by user /users/guest for
> action /actions/read
> [exec] 04 Aug 2003 16:53:07 -
> org.apache.slide.common.Domain -
> WARNING - Ac
> cess denied on /actions by user /users/guest for
> action /actions/read
> [exec] 04 Aug 2003 16:53:07 - WARNING -
> WARNING: No active
> transaction
> [exec] 04 Aug 2003 16:53:07 -
> org.apache.slide.webdav.WebdavServlet
> - INFO
> - GET = 200 OK (time: 110 ms) URI = /
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> slide-user-help@jakarta.apache.org
>
=====
Live simply so others may simply live.
�
-Ghandi
�
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
�
-William of Occam
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
How can we add users?
Posted by Aruna Goli <ar...@covigna.com>.
Hello
I got slide to deploy on weblogic and when I start up the server and
go to the first page
http://localhost:7001/slide I am able to view a listing of the files but
I cannot perform any actions.
How do I add the users to the system, similar to tomcat-users.xml
Thanks
Aruna
This is what I get on my console
[exec] 04 Aug 2003 16:53:07 - WARNING - WARNING: No active
transaction
[exec] 04 Aug 2003 16:53:07 - org.apache.slide.common.Domain -
WARNING - Ac
cess denied on /users by user /users/guest for action /actions/read
[exec] 04 Aug 2003 16:53:07 - org.apache.slide.common.Domain -
WARNING - Ac
cess denied on /actions by user /users/guest for action /actions/read
[exec] 04 Aug 2003 16:53:07 - WARNING - WARNING: No active
transaction
[exec] 04 Aug 2003 16:53:07 - org.apache.slide.webdav.WebdavServlet
- INFO
- GET = 200 OK (time: 110 ms) URI = /
How can we add users?
Posted by Aruna Goli <ar...@covigna.com>.
Hello
I got slide to deploy on weblogic and when I start up the server and
go to the first page
http://localhost:7001/slide I am able to view a listing of the files but
I cannot perform any actions.
How do I add the users to the system, similar to tomcat-users.xml
Thanks
Aruna
This is what I get on my console
[exec] 04 Aug 2003 16:53:07 - WARNING - WARNING: No active
transaction
[exec] 04 Aug 2003 16:53:07 - org.apache.slide.common.Domain -
WARNING - Ac
cess denied on /users by user /users/guest for action /actions/read
[exec] 04 Aug 2003 16:53:07 - org.apache.slide.common.Domain -
WARNING - Ac
cess denied on /actions by user /users/guest for action /actions/read
[exec] 04 Aug 2003 16:53:07 - WARNING - WARNING: No active
transaction
[exec] 04 Aug 2003 16:53:07 - org.apache.slide.webdav.WebdavServlet
- INFO
- GET = 200 OK (time: 110 ms) URI = /
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
Posted by "K.C. Baltz" <kc...@lollimail.com>.
+1
>
>
Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
Posted by joe <li...@concrete-it.com>.
+1
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
Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
Posted by joe <li...@concrete-it.com>.
+1
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
>
>
>
>
>
Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
Posted by "K.C. Baltz" <kc...@lollimail.com>.
+1
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: [VOTE] HttpClient and WebDAV methods will do no additional
encodi ng
Posted by 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
Re: [VOTE] HttpClient and WebDAV methods will do no additional encoding
Posted by Jean-Philippe Courson <ju...@apache.org>.
+1
----- Original Message -----
From: "Pill, Juergen" <Ju...@softwareag.com>
To: <sl...@jakarta.apache.org>; "'Slide Developers Mailing List'"
<sl...@jakarta.apache.org>
Sent: Monday, August 04, 2003 8:11 AM
Subject: [VOTE] HttpClient and WebDAV methods will do no additional encoding
> 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
>
>
>
Re: [VOTE] HttpClient and WebDAV methods will do no additional encoding
Posted by Jean-Philippe Courson <ju...@apache.org>.
+1
----- Original Message -----
From: "Pill, Juergen" <Ju...@softwareag.com>
To: <sl...@jakarta.apache.org>; "'Slide Developers Mailing List'"
<sl...@jakarta.apache.org>
Sent: Monday, August 04, 2003 8:11 AM
Subject: [VOTE] HttpClient and WebDAV methods will do no additional encoding
> 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-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
Posted by Ingo Brunberg <ib...@fiz-chemie.de>.
Here's my +1 (of course).
Regards,
Ingo
> 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-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: [VOTE] HttpClient and WebDAV methods will do no additional encodi
ng
Posted by Ingo Brunberg <ib...@fiz-chemie.de>.
Here's my +1 (of course).
Regards,
Ingo
> 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
Re: [VOTE] HttpClient and WebDAV methods will do no additional
encodi ng
Posted by 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
>
>