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

Ang: AW: JSP page directive contentType overriden by Apache tomcat?

From: Markus Gylling <markus.gylling@tpb.se>
Date: Mon, 02 Aug 2004 14:19:15 +0200
Message-Id: <s10e4d7e.051@nw1.tpb.se>
To: <jshin@i18nl10n.com>, <Paul.Deuter@plumtree.com>, <www-international@w3.org>

We have fixed the jsp pages encoding problem by setting it via struts 
org.apache.struts.tiles.TilesRequestProcessor#processPreprocess 
that is called for every request. 

What we do is call 
org.apache.struts.tiles.TilesRequestProcessor#setContextEncoding
which sets the encoding by retrieving a context parameter defined in
the deployment descriptor (web.xml)
    <context-param>
        <param-name>contextDefaultEncoding</param-name>
        <param-value>utf-8</param-value>
    </context-param>

Seems to work fine and saves us doing anything in the jsp pages.

/Piotr Kiernicki

Markus Gylling
International Technical Development Coordinator
the DAISY Consortium
www.daisy.org 

Software Development Manager
TPB - The Swedish Library of Talking books and Braille
Sandsborgsvägen 52 12288 Enskede
Telephone: +46 8 399350
Fax: +46 8 6599467
www.tpb.se

>>> "Paul Deuter" <Paul.Deuter@plumtree.com> 2004-07-17 00:24 >>>
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
 

-----Ursprüngliche 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
Received on Monday, 2 August 2004 08:22:58 GMT

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