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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
