W3C home > Mailing lists > Public > www-international@w3.org > July to September 2004

AW: JSP page directive contentType overriden by Apache tomcat?

From: Paul Deuter <Paul.Deuter@plumtree.com>
Date: Fri, 16 Jul 2004 15:58:15 -0700
Message-ID: <66EA32F2A81C004AB67268BA33833EA0FCB40C@corpexch05.plumtree.com>
To: <andrea.vine@sun.com>, <aphillips@webmethods.com>
Cc: "Jungshik Shin" <jshin@i18nl10n.com>, <www-international@w3.org>
Note: If you are using Tomcat 4.1.30 then you must use JSTL 1.0.  It is JSTL 1.0 that has the side-effect of setting the content-type header.  This bug has been fixed in later versions of JSTL, but they require you to use a later version of Tomcat too.

The current documentation on JSTL is misleading because it makes it sound as if all you have to do is use a later version and then you are fine.

If you must use Tomcat 4.1.30, then your choices are to get the JSTL 1.0 source and add code to set the content-type back to its original value or to avoid using the fmt tags.

-Paul 

-----Ursprüngliche Nachricht-----
Von: A. Vine [mailto:andrea.vine@sun.com] 
Gesendet: Friday, July 16, 2004 3:31 PM
An: aphillips@webmethods.com
Cc: Paul Deuter; Jungshik Shin; www-international@w3.org
Betreff: Re: JSP page directive contentType overriden by Apache tomcat?

This article may help:
http://java.sun.com/developer/technicalArticles/Intl/MultilingualJSP/


Addison Phillips [wM] wrote:

> ... and watch out for custom filters! They can cause the problems you're experiencing (by modifying the content type or setting the locale) and may not show up anywhere in your JSP or its references.
> 
> Addison
> 
> Addison P. Phillips
> Director, Globalization Architecture
> webMethods | Delivering Global Business Visibility 
> http://www.webMethods.com Chair, W3C Internationalization (I18N) 
> Working Group Chair, W3C-I18N-WG, Web Services Task Force 
> http://www.w3.org/International

> 
> Internationalization is an architecture. 
> It is not a feature.
> 
> 
>>-----Original Message-----
>>From: www-international-request@w3.org 
>>[mailto:www-international-request@w3.org]On Behalf Of Paul Deuter
>>Sent: 2004年7月16日 15:25
>>To: Jungshik Shin; www-international@w3.org
>>Subject: AW: JSP page directive contentType overriden by Apache tomcat?
>>
>>
>>Hi Jungshik,
>>
>>We have seen problems like this too.  When we have investigated, we 
>>found that a call to response.setLocale will cause the content-type 
>>header to be overwritten.  This will happen if you use any of the fmt 
>>tags in JSTL.
>>
>>We ended up resetting the content-type several times.  This workaround 
>>is problematic because you can only re-set the content-type when the 
>>response has not been committed.  If the response buffer is small and 
>>the response content is large, then the first buffer will be sent and 
>>after that point, you can no longer change the content-type header.
>>
>>-Paul
>> 
>>
>>-----Ursprungliche Nachricht-----
>>Von: www-international-request@w3.org 
>>[mailto:www-international-request@w3.org] Im Auftrag von Jungshik Shin
>>Gesendet: Friday, July 16, 2004 2:41 PM
>>An: www-international@w3.org
>>Betreff: Re: JSP page directive contentType overriden by Apache tomcat?
>>
>>
>>Jungshik Shin wrote:
>>
>>I'm sorry I forgot to mention that I use Tomcat 4.1.30 on Mac OS X 
>>with Java 1.4.2 (the latest available for Mac OS 10.3.x)
>>
>>
>>>
>>>
>>>Following the standard-step of adding contentType and pageEncoding 
>>>directives at the beginning of jsp files (I also added 
>>>request.setCharacterEncoding("UTF-8");
>>>along with making sure that
>>>that's honored because recent versions of Apache tomcat by default 
>>>ignores that for GET), I expected everything to work. To my great 
>>>surprise, all the JSP files with 'contentType="text/html; 
>>>charset=UTF-8"' directive still emit 'Content-Type:text/html; 
>>>charset=ISO-8859-1'
>>>in HTTP header. Even more surprsing is that cached versions of 
>>>translated java source files for those jsp files have the following
>>>line:
>>>
>>>response.setContenttype("text/html; charset=UTF-8");
>>>
>>>It's completely beyond me how I've been getting  'text/html; 
>>>charset=ISO-8859-1' despite that.
>>>e.
>>>
>>
>>Even more strange is that everything works perfectly when I connect 
>>with Safari (locally - http://localhost:8080/.....) while on the same 
>>host Mozilla does have a problem. So does a remote Mozilla and MS IE.  
>>Is there any built-in 'charset' negotiation mechanism in Tomcat (or 
>>JSP container in general)?
>>
>>Jungshik
>>
>>
>>
> 
> 

--
I have always wished that my computer would be as easy to use as my telephone. 
My wish has come true. I no longer know how to use my telephone.
-Bjarne Stroustrup, designer of C++ programming language (1950- )


Received on Friday, 16 July 2004 18:58:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:03 GMT