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

Tomcat with mod_jk does not serve up files with names containing % character

           Summary: Tomcat with mod_jk does not serve up files with names
                    containing % character
           Product: Tomcat 5
           Version: 5.0.22
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Connector:Coyote
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


With Tomcat 5.0.22, Apache 2.0.49, and mod_jk 1.2.6-dev (i.e. CVS head as of 
3/31/04):

1) Create a file (e.g. a text file) with a name containing a % character (e.g. 
foo%bar.txt).
2) Place it somewhere in the doc base of a web app.
3) Attempt to navigate to this document via a browser.

You'll be able to see such files in directory listings, but not download them 
(you get 404's instead)!

Note that the links for such files in the directory listings *do* have the % 
properly escaped as %25, but the request still does not work.  Note that using 
Tomcat 4.1.24 instead of 5.0.22 produces the same result.

Apache 2.0.49 has no such issues, though I believe some previous versions had 
issues in this area.

I am not certain which component of the architecture is at fault here.

I am actually more concerned with the overall treatment of % in path-info by 
mod_jk, Coyote, and Tomcat 4.1 and 5 than by the static file serving itself 
(which we use Apache for).  I have servlets which do not get requests when 
their path-info contains % characters.  I'll file a separate bug on this issue.

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

Reply via email to