Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <495CBE12.2030302@ice-sa.com>
Date: Thu, 01 Jan 2009 13:58:58 +0100
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: mod_perl list <modperl@perl.apache.org>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: mod_perl list <modperl@perl.apache.org>
Subject: Re: HTTP Response Headers fixup
References: <495B5878.6050402@ice-sa.com> <495B9C1D.3000800@norchemlab.com>
In-Reply-To: <495B9C1D.3000800@norchemlab.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

As a complement to this thread, I would like to reproduce an answer 
received on the Tomcat list, from Rainer Jung, the developer/maintainer 
of the mod_jk module.
It explains why I wasn't (and can't) get any success doing what I wanted 
with either mod_headers or a mod_perl connection output filter (which I 
tried).

Rainer Jung :

Apache 2 has hooks for modules, but also filters. The hooks allow to 
interact with request processing at certain stages and the modules 
decide, whether they allow other modules to be called in the same hook.

mod_headers is a filter, which allows to manipulate requests and 
responses much like servlet filters during the reading and writing of 
request resp. response. Thus you can use mod_headers to change headers 
after they are returned by mod_jk.

Unfortunately the Content-Type header is a different beast. Inside 
Apache it is not only a response header, but a more complex data type. 
You can set a different Content-Type header with mod_headers, but since 
the internal structure remains unchanged it will be overwritten again by 
Apache.

As a result I see no way to change an existing character set in a 
Content-Type header.

 > I have tried changing the Content-Type header in a servlet filter under
 > Tomcat. However, that also has the side-effect that the servlet then,
 > for its response, really uses the new character encoding specified in
 > the header, to produce its response.
 > That is not what I want here, because the problem is that the servlet
 > response is already correct (in the iso-8859-2 encoding), it is just
 > that the Content-Type header is incorrect and does not match the real
 > charset of the response. The underlying reason for all that stuff is
 > obscure and OT here, but that is really what happens.

See javax.servlet.ServletResponseWrapper. A filter can replace request 
and/or response with a custom wrapper object. Whenever the servlet then 
calls a method of the request or response object, your custom object is 
called. Your custom response wrapper extends the standard one, which 
itself lets all methods call through to the wrapped response. You can 
then implement individual methods in a different way. You could for 
instance overwrite setCharacterEncoding(java.lang.String charset) to set 
something else, then demanded by the caller (e.g. iso-8859-2 instead of 
iso-8859-1), and getCharacterEncoding() to return something different, 
from what you actually set.

The filter can inspect e.g. the URL to decide, whether it should wrap 
the response or not.

This mechanism can be used without any changes to the existing webapp 
code, you only need to add your filter and wrapper to the webapp, and of 
course add the filter to web.xml.

Regards,

Rainer