Bug 41773 - DefaultServlet doesn't set correct content type
Summary: DefaultServlet doesn't set correct content type
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.20
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on: 31201
Blocks:
  Show dependency tree
 
Reported: 2007-03-06 11:47 UTC by Brett Knights
Modified: 2007-03-06 14:01 UTC (History)
0 users


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Brett Knights 2007-03-06 11:47:33 UTC 
This is a continuation of bug #31201. The fileEncoding parameter on the
DefaultServlet doesn't go far enough. 
The case I have is this:
I have a webapp that serves some static html files directly to end user. They
are encoded in shift_jis. With the current implementation the response header
says the charset is iso-8859-1 for my jvm. So now I can see the correct
characters in the result page but only if I explicitly tell the browser to show
the page in shift_jis.

I believe the DefaultServlet also needs to pass along the fileEncoding parameter
as the charset in the response content type.

I added the following line to the Default Servlet and it now returns a sensible
content type header for any static html  or text files in my web application.

Compare:
(<)\apache-tomcat-5.5.20-src\container\catalina\src\share\org\apache\catalina\servlets\DefaultServlet.java


738d738
<             if(contentType.toLowerCase().indexOf("charset") == -1 &&
fileEncoding != null) contentType += ";charset="+fileEncoding; 

It would be great if this could be applied to the official tomcat distribution.
Thanks
Comment 1 Remy Maucherat 2007-03-06 14:01:07 UTC 
You can easily use your own extended servlet. I believe the current one provides
the necessary features encoding wise.