tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thierry Templier <temp...@yahoo.fr>
Subject Re: mojk and utf8 charset problem
Date Mon, 02 May 2011 08:31:36 GMT
Hi André,

Thanks very much for your help!

I checked difference between two access:

- Using Apache / modjk / Tomcat that can't display correclty non latin1 characters
- Directly using Tomcat that works fine

Except characters that don't display correctly content are the same, especially meta tags
at the beginning:

<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8"></meta>

As suggested, I also have a look at request / response content and it seems that there are
some different, as described below.

- Response headers when using Apache / Modjk / Tomcat:

Date	Mon, 02 May 2011 08:21:16 GMT
Server	Apache/2.2.14 (Ubuntu)
Pragma	no-cache
Expires	Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control	no-cache, no-store
Content-Language	en-UK
Vary	Accept-Encoding
Content-Encoding	gzip
Content-Length	2494
Keep-Alive	timeout=15, max=93
Connection	Keep-Alive
Content-Type	text/html;charset=UTF-8

- Response headers when directly using Tomcat:

Server	Apache-Coyote/1.1
Pragma	no-cache
Expires	Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control	no-cache, no-store
Content-Type	text/html;charset=UTF-8
Content-Language	en-UK
Transfer-Encoding	chunked
Date	Mon, 02 May 2011 08:19:39 GMT

The content type header is the same and specifies UTF-8 as encoding... However it appears
that when using Apache / modjk / Tomcat, the reponse content is compressed using gzip. It's
not the case when directly accessing Tomcat. I don't know if it could be the reason of the
problem...

Thierry

> Hi.
> 
> I suggest to get one of the browser add-ons which allow to
> display the complete HTTP response from the webserver to the
> browser (iow the HTTP headers as well as the content).
> For Firefox, you can use for example HttpFox; for IE, there
> is Fiddler2. A quick search in Google will lead you to the
> download page.
> 
> Install one of those, re-do your server request, and
> carefully compare what you get back
> a) from Tomcat directly
> b) from Apache + mod_jk + tomcat
> 
> The way that a browser will display a page (in terms of
> charset) depends on 3 elements :
> 
> 1) when the server sends a response, it includes a
> "Content-type" HTTP header, which in this case should be
> something like :
> Content-type: text/html; charset=UTF-8
> 
> 2) any <meta> tags included inside the <head>
> portion of the html page.
> For example, a tag such as :
> <meta http-equiv="content-type" value="text/html;
> charset=UTF-8" />
> 
> 3) the way in which the browser (each specific browser, and
> sometimes even version) interprets the above.
> 
> According to the HTTP RFCs, the browser SHOULD NOT
> "second-guess" what the server says in terms of
> content-type. In other words, if the server says
> Content-type: something; charset=somecharset
> then the browser should blindly follow this, and not make
> its own determination.
> 
> However, IE for one is notorious for not following this
> aspect of the RFCs, and constantly trying to determine by
> itself what it is receiving, often in contradiction to what
> the server says. And worse, the determination it makes
> depends on the version of IE, and sometimes even on the
> patches applied to ir or to Windows.
> 
> Also,
> 3a) ultimately, it is the user who is in control.  In
> the browser settings, there is a way to override the above,
> and force the browser to always display the page in a
> specific character set.  It does not sound that this is
> an issue in your case, but better check anyway.
> 
> But first, make sure that what you are receiving in one
> case or the other is really the same, headers and content.
> And maybe also try it with different browsers, to see if
> the result is always the same.
> 
> Once you know the answer to that, then you can start
> looking for the issue in a more focused way.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message