Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <495BDEAE.4080706@kippdata.de>
Date: Wed, 31 Dec 2008 22:05:50 +0100
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [users@httpd] Problem with mod_headers ?
References: <495A762B.3090101@ice-sa.com>
 <a2d59f0d0812301221t2c6da8e7y4021cee4e8c88081@mail.gmail.com>
 <495A91DF.1030202@ice-sa.com>	 <495B3264.7060105@iki.fi>
 <495B368D.3010107@ice-sa.com>
In-Reply-To: <495B368D.3010107@ice-sa.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

On 31.12.2008 10:08, Andr� Warnier wrote:
> Juha Laiho wrote:
> [...]
> Thanks, Juha. That helps me think in another direction.
> Maybe indeed in this case the mod_headers module does not get a chance
> to modify the response headers, because it is added before the mod_jk
> module, and mod_jk overrides it.
> It is worth investigating anyway, since the other solutions I can see
> are a lot heavier in my case (output filter or trying mod_proxy_ajp).

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

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