DO NOT REPLY [Bug 30368] - Problem with URLDecode

2004-08-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30368.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30368

Problem with URLDecode





--- Additional Comments From [EMAIL PROTECTED]  2004-08-10 07:56 ---
Mark thanks for your reply.
My expected behaviour was (and still is) that the servlet container should make 
no assumption about an encoding of the URI. getPathInfo() should URLdecode the %
xx characters but nothing else. The further interpretation should be in the 
responsibility of my servlet, i.e. in our case we UTF-8-decode the servlet path 
as well as the query string. From your comment I read that you consider 
querystring parameters the same as servlet paths but the default behaviour in 
Tomcat is not the same.
As I wrote we have passed UTF-8-Strings via querystring parameters for a long 
time. getParameter() does the URLdecoding and afterwards we manually UTF-8-
decode this string.
Now we have started to use the servlet path and use getPathInfo() and expected 
the same and run into the problem described here.
With your connector attributes I think we should Tomcat let UTF-8-decode the 
URL but then we have to omit the UTF-8-decoding from our servlet. But is that 
portable across other servlet containers? We will not use your suggestion but 
use our own implementation of getPathInfo().

Again in short: IMO the servlet path obtained by getPathInfo() should be 
handled the same way as the querystring handled by getParameter().

Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 30368] - Problem with URLDecode

2004-07-31 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30368.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30368

Problem with URLDecode

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-07-31 18:14 ---
Character encoding in URLs is often problematic. Set the following parameters 
on your connector and all should be OK:
URIEncoding=UTF8
useBodyEncodingForURI=false

This has caused much confusion in the past. In an attempt at clarification I 
put together the following notes that might be helpful.

REQUESTS


There are a number of situations where there may be a requirement to use non-
US ASCII characters in a URI. These include:
- Parameters in the query string
- Servlet paths

There is a standard for encoding URIs (http://www.w3.org/International/O-URL-
code.html) but this standard is not consistently followed by clients. This 
causes a number of problems.

The functionality provided by Tomcat (4 and 5) to handle this less than ideal 
situation is described below.

1. The Coyote HTTP/1.1 connector has a useBodyEncodingForURI attribute which 
if set to true will use the request body encoding to decode the URI query 
parameters.
  - The default value is true for TC4 (breaks spec but gives consistent 
behaviour across TC4 versions)
  - The default value is false for TC5 (spec compliant but there may be 
migration issues for some apps)
2. The Coyote HTTP/1.1 connector has a URIEncoding attribute which defaults to 
ISO-8859-1.
3. The parameters class (o.a.t.u.http.Parameters) has a QueryStringEncoding 
field which defaults to the URIEncoding. It must be set before the parameters 
are parsed to have an effect.

Things to note regarding the servlet API:
1. HttpServletRequest.setCharacterEncoding() normally only applies to the 
request body NOT the URI.
2. HttpServletRequest.getPathInfo() is decoded by the web container.
3. HttpServletRequest.getRequestURI() is not decoded by container.

Other tips:
1. Use POST with forms to return parameters as the parameters are then part of 
the request body.


RESPONSES
=

HTML META tags are ignored by Tomcat. You may use %@ page pagEncoding=... %
 for JSPs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 30368] - Problem with URLDecode

2004-07-29 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=30368.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30368

Problem with URLDecode





--- Additional Comments From [EMAIL PROTECTED]  2004-07-29 06:01 ---
BTW, our app has been Unicode enabled for a long time, so I am sure there is 
really a problem. Up to now we have passed all as request parameters and 
getParameter() has been always URLdecoded correctly. So there must be a 
difference in Tomcat between URLencoding the parameters and the pathInfo.

Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]