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: Sat, 17 Jul 2004 12:31:30 -0700
Message-ID: <66EA32F2A81C004AB67268BA33833EA0FCB4B2@corpexch05.plumtree.com>
To: <kuro@sonic.net>, <www-international@w3.org>

If you use a content type page directive in your JSP, the resultant java code will have a call to response.setContentType corresponding to your directive.  But there is nothing that stops other code from also calling setContentType with yet a different character set.

Each time you call setContentType, the response will change the character set of the output stream.  It is the output stream associated with the response that performs the transcoding.  The charset in the content-type header will always match the charset of the output stream.

That is why the flushBuffer workaround works.  Once the output stream has sent bytes out the door, then it is too late to change the charset of the stream.  And therefore calling setContentType will also not change the content-type header.  The setContentType method just simply returns if the response has been committed.


-----Ursprüngliche Nachricht-----
Von: www-international-request@w3.org [mailto:www-international-request@w3.org] Im Auftrag von KUROSAKA Teruhiko
Gesendet: Saturday, July 17, 2004 11:58 AM
An: www-international@w3.org
Betreff: Re: JSP page directive contentType overriden by Apache tomcat?

Sorry for my poor analysis about META.  I agree META won't work.

I see, so it's setLocale() that implicitly sets charset.
That reminded me of my surprise when I read the servlet 2.3 spec draft for the first time two years ago.  I wasn't comfortable with the idea of using  the locale to determine the charset.  I voiced this opinion to the spec lead but it was too late.

Anyway, it makes sense that flushing before setLocale would fix this problem.  But I still don't understand why the generated Java code from the JSP with "contentType=text/html;charset=ISO-8859-1" can include this line:
     response.setContenttype("text/html; charset=UTF-8") as Jungshik indicated.

This is the result of static compilation and there is no way for JSP compiler to predict that a locale that should be mapped to UTF-8 will be used at the execution time.  Any idea?

KUROSAKA ("Kuro") Teruhiko, San Francisco, California, USA Internationalization Consultant --- now accepting new projects!
Received on Saturday, 17 July 2004 15:32:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:24 UTC