Some browsers have an unusual breakage: when they receive a
redirect, and the redirect response's content-type includes a
charset, they remember the charset and apply it to the target
of the redirection -- overriding any charset the target's
response specifies.
This gets tickled when the redirect is coming out of any
internal Apache mechanism, since we explicitly set the
charset on those. If the redirect is to a page in Greek,
for instance, the browser is going to try to render it in
iso-8859-1.
This is a client bug to be sure, but in a widely-deployed
browser: Netscape 4.
The following patch allows this to be worked around using our
standard BrowserMatch envariable mechanism. It's against
1.3, since that's the version with the most penetration at
the moment and where the problem is most visible.
Index: src/main/http_protocol.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.325
diff -u -r1.325 http_protocol.c
--- src/main/http_protocol.c 9 Jul 2002 15:26:26 -0000 1.325
+++ src/main/http_protocol.c 12 Aug 2002 16:24:39 -0000
@@ -2834,7 +2834,13 @@
r->content_languages = NULL;
r->content_encoding = NULL;
r->clength = 0;
- r->content_type = "text/html; charset=iso-8859-1";
+ if (ap_table_get(r->subprocess_env,
+ "suppress-error-charset") != NULL) {
+ r->content_type = "text/html";
+ }
+ else {
+ r->content_type = "text/html; charset=iso-8859-1";
+ }
if ((status == METHOD_NOT_ALLOWED) || (status == NOT_IMPLEMENTED))
ap_table_setn(r->headers_out, "Allow", make_allow(r));
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
