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