DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7277>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7277

request URI processing works wrong

           Summary: request URI processing works wrong
           Product: Tomcat 4
           Version: 4.0.4 Beta 1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Connector:Other
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


tomcat 4 does not allow escaped character %2f ('/') (HttpProcessor.java) in the
path. it is contradictory to HTTP specification, and it is significant, since
some applications use this character in the pathInfo.

it is not clear how it should be interpreted -- on the one hand, URI
specification allows it _inside_ path elements, on the other hand, HTTP/1.1
specification suggest to treat it the same way as '/'.

in both cases it shouldn't be disallowed.

from "Hypertext Transfer Protocol -- HTTP/1.1"
-------------------------------------------------------------------------
For definitive information on URL syntax and semantics,
see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC
2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]).
-------------------------------------------------------------------------

from "Uniform Resource Identifiers (URI): Generic Syntax and Semantics":
-------------------------------------------------------------------------
2.2. Reserved Characters

   Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

      reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                    "$" | ","

   The "reserved" syntax class above refers to those characters that are
   allowed within a URI, but which may not be allowed within a
   particular component of the generic URI syntax; they are used as
   delimiters of the components described in Section 3.

...

2.4.2. When to Escape and Unescape

   A URI is always in an "escaped" form, since escaping or unescaping a
   completed URI might change its semantics.  Normally, the only time
   escape encodings can safely be made is when the URI is being created
   from its component parts; each component may have its own set of
   characters that are reserved, so only the mechanism responsible for
   generating or interpreting that component can determine whether or
   not escaping a character will change its semantics. Likewise, a URI
   must be separated into its components before the escaped characters
   within those components can be safely decoded.
-------------------------------------------------------------------------

however,

from "Hypertext Transfer Protocol -- HTTP/1.1":
-------------------------------------------------------------------------
3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client SHOULD use a
case-sensitive octet-by-octet comparison of the entire URIs, with these
exceptions:

      - A port that is empty or not given is equivalent to the default
        port for that URI-reference;

        - Comparisons of host names MUST be case-insensitive;
        - Comparisons of scheme names MUST be case-insensitive;
        - An empty abs_path is equivalent to an abs_path of "/".

Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396
[42]) are equivalent to their ""%" HEX HEX" encoding.

...

If the Request-URI is encoded using the "% HEX HEX" encoding [42], the origin
server MUST decode the Request-URI in order to properly interpret the request.
Servers SHOULD respond to invalid Request-URIs with an appropriate status code.
---------------------------------------------------------------------------

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

Reply via email to