tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 9326] New: - Long URLs for JSPs cause HTTP 404/500 errors
Date Wed, 22 May 2002 19:14:03 GMT
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=9326>.
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=9326

Long URLs for JSPs cause HTTP 404/500 errors

           Summary: Long URLs for JSPs cause HTTP 404/500 errors
           Product: Tomcat 3
           Version: 3.2.3 Final
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Jasper
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: andrewprevost@hotmail.com


While testing one of our applications we noticed that whenever we tried to hit
any of the JSP files in a particular directory, we always got 404 errors - even
though the files were definitely there. We tried moving those same JSP files to
other directories - in some directories they worked fine, in others we got 404
errors, an in still others we got 500 errors telling us Tomcat was unable to
create the .class file. Same thing when we moved JSPs that worked in other
directories into the directory where we originally noticed the problem - some
still worked, some always gave 404 errors, some gave 500 errors.

It took us several days to debug this, but we were finally able to determine
that it was the length of the JSP URLs that was causing the problem. Or more
precisely, the length of the filenames of the .java and .class files that Tomcat
produces when compiling the JSPs.

When Tomcat tries to compile the following JSP (with full path from the
application root, application name was osdm-address):

en.us/prompts/default_dm/address/56789012345.jsp

The filename of the .class file that it attempts to compile (cut and pasted this
directly from the HTTP 500 error message) is:

C:\Program Files\Apache
Group\jakarta-tomcat-3.2.3\work\localhost_8080%2Fosdm-address\en_0005fus\prompts\d_00025fault_0005fdm\address\_0002fen_0002eus_0002fprompts_0002fdefault_0005fdm_0002faddress_0002f_00035_00036_00037_00038_00039_00030_00031_00032_00033_00034_00035_0002ejsp56789012345_jsp_0.class

This is longer than 255 characters, which is the NTFS limit for file names.

I suspect that the 404 error occurs when the intermediate .java filename is too
long, and the 500 error occurs when the final .class filename is too long. Or
something like that, my experimentation shows extremely long URLs lead to 404
errors, whereas somewhat shorter URLs lead to the 500 error.

You should note that we had previously tested this same application on JRun and
found everything worked fine. Reason being that JRun uses a different naming
scheme for these temporary files, one which results in shorter filenames. The
difference is in the way non-alphabetic characters like '/' or '_' that may
appear in the original URL are converted. JRun just replaces all
non-alphanumeric characters with an underscore. Tomcat, on the other hand, seems
to convert all non-alphabetic characters (including digits) into an underscore
followed by a 5-character hex representation of the ASCII value for that
character. That can add up to a lot of characters pretty quick if your URL has a
lot of non-alphabetic characters!

Obviously there is a work-around - to simplify our directory structure, shorten
the directory and file names we're using, and/or try to eliminate non-alphabetic
characters from directory and file names. But it seems like that shouldn't be
necessary, I think the length and format of our URLs is quite reasonable. At the
very least, even if you decide not to allow longer path/filenames, you should
make sure that when the max is exceeded the error messages produced by Tomcat
are more verbose and explain exactly why the JSP cannot be loaded, rather than
just producing generic 404 or 500 errors.

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


Mime
View raw message