Bug 28351 - If path-info contains % character(s), servlet will not receive request
Summary: If path-info contains % character(s), servlet will not receive request
Status: RESOLVED DUPLICATE of bug 28350
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:Coyote (show other bugs)
Version: 5.0.22
Hardware: All All
: P3 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-12 18:33 UTC by Jess Holle
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jess Holle 2004-04-12 18:33:42 UTC
With Apache 2.0.49, Tomcat 5.0.22, mod_jk 1.2.6-dev (or mod_jk2 2.0.5-dev), my 
servlets' service methods do not get called if there is a % character in the 
path-info.

The URLs in question are properly escaped originally and are of the form:

http://hostname/webappname/servlet/servletName/pathComp1/pathComp2/foo%25bar.txt

Note that the request is processed without any error if the %25 (an 
escaped '%') is omitted.  Once the % is in place, however, my service method is 
never invoked.

On Apache's side mod_jk logs show delegation of the request 

  /webappname/servlet/servletName/pathComp1/pathComp2/foo%bar.txt

to Tomcat.  Note that the %25 has been unescaped here.

These logs then shows mod_jk unmarshals a 400 response.

I am not certain which component is to blame here, but:
1) The original URL is valid (albeit obnoxious...)
2) Static requests for paths with % in them have related issues. See bug 28350.
Comment 1 Remy Maucherat 2004-04-12 20:49:40 UTC
I recommend giving your resources more sensible names. As this might cause
security issues, I don't think it would be wise fixing this.

*** This bug has been marked as a duplicate of 28350 ***
Comment 2 Jess Holle 2004-04-12 21:23:54 UTC
Was this resolved due to
  JkOptions ForwardURICompatUnparsed
as in the other bug?  [I've not had a chance to test this yet.]

If so, great.

To answer your security question, the resource is not named by me,
unfortunately.  The request is for content management and maintains the user's
original leaf filename for better handling by browsers, etc.  While I would
never put '%' in a filename, users do all sorts of crazy things...