tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] Problem with mod_headers ?
Date Thu, 01 Jan 2009 11:59:14 GMT
Rainer Jung wrote:
> 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.
> 
Thanks for your very clear response, Rainer.
This will save me a lot of time trying unworkable solutions, such as 
trying mod_proxy_ajp instead of mod_jk.
I also tried a mod_perl connection output filter in the meantime (based 
on Apache2::Filter::HTTPHeadersFixup), with no more success. Your 
explanation above makes clear why.
To wrap us thus :
- with mod_headers or another Apache or mod_perl connection output 
filter, one *can* modify response headers set by a Tomcat application 
and returned through mod_jk (or whatever), but the Content-Type header 
is a special case.  It will also be in fact modified by the above, but 
Apache will in the end override that modification and restore the 
original Content-Type header, based on some internal information.
This has nothing to do with mod_jk itself, it is a generic Apache 
mechanism for the Content-Type header in particular.

- the only viable solution in my case is thus to make sure that the 
Tomcat servlet issues the correct Content-Type header in the first 
place.  If the servlet itself cannot be modified, then a servlet filter 
wrapping the response in a javax.servlet.ServletResponseWrapper wrapper 
would be the way to go.  The wrapper should override the methods by 
which the servlet sets and/or obtains the response encoding.

(In my case, the servlet has to "keep believing" that its response 
output stream is iso-8859-1, otherwise it does the wrong charset 
translations from its internal Unicode strings to the 8-bit response 
stream.)



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


Mime
View raw message