Apache Content-Type encoding changing from UTF-8 to iso-88591 from directory to directory

apache-2.2content-negotiationencoding

I have a site running on Apache 2.2.8 (Plesk 9.5.4)

For this site there is a strange behaivor the root directory only has html and it is served with the following header with is great.

http://globalmit.com/
Response Headers
Date Wed, 04 May 2011 00:57:26 GMT
Server Apache
Last-Modified Mon, 04 Apr 2011 21:09:05 GMT
Etag "15013bf-5a7-4a01e2b6efe40"
Accept-Ranges bytes
Cache-Control max-age=300
Expires Wed, 04 May 2011 01:02:26 GMT
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 564
Content-Type text/html; charset=utf-8

Then I have osTickets installed on this directory, and I made the translation to Spanish and for it to work the content type encoding needs to be set to UTF-8 which is and it is working great.

http:// globalmit.com/ tickets/
Response Headers
Date Wed, 04 May 2011 01:04:37 GMT
Server Apache
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Vary Accept-Encoding
Content-Encoding gzip
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=UTF-8

Here comes the problem for this directory, the admin panel of osTickets, Apache is changing the encoding to iso-8859-1 for no reason.

I have tried adding a AddDefaultCharset UTF-8 to the Apache virtual directory configuration file, adding a .htaccess file with the same AddDefaultCharset UTF-8 but I have no luck.

http://globalmit.com/tickets/scp/
Response Headers
Date Wed, 04 May 2011 01:05:26 GMT
Server Apache
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Vary Accept-Encoding
Content-Encoding gzip
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html; charset=iso-8859-1

How can I avoid this strange Apache behavior?

Best Answer

Apache is behaving correctly; PHP is not.

Unfortunately, since all of the string data is being generated out of PHP, you're pretty much dependent on the application you're running having good character set support - look into whether there are any settings you can modify in the application to enable UTF-8 support.

Related Topic