You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2004/08/03 09:41:07 UTC

DO NOT REPLY [Bug 30369] - Wrong result of getPathInfo

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=30369>.
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=30369

Wrong result of getPathInfo

Jochen.Schwarze@cit.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |



------- Additional Comments From Jochen.Schwarze@cit.de  2004-08-03 07:41 -------
tricky question. rfc 1738, section says:

   Many URL schemes reserve certain characters for a special meaning:
   their appearance in the scheme-specific part of the URL has a
   designated semantics. If the character corresponding to an octet is
   reserved in a scheme, the octet must be encoded.  The characters ";",
   "/", "?", ":", "@", "=" and "&" are the characters which may be
   reserved for special meaning within a scheme. No other characters may
   be reserved within a scheme.

my interpretation is that the server must surely decode the request-uri (rfc
2616) but it must do so component by component. ie, first separate the uri
components at the *un*encoded separator characters like ';' '?' '#' etc., then
decode each component by its own: 

http://server/PATH;jessionid=9999?QUERY#FRAG

PATH, QUERY and FRAG may each contain one or more of the reserved characters ';'
'?' and '#' in encoded form. (otherwise, there would be no point in encoding
reserved characters at all.) especially, these characters should be able to
appear in PATH, because these are all valid characters in unix filenames.

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