Hi.
I have a peculiar problem, and need a peculiar solution.
In an Apache 2.2.3, mod_jk, Tomcat 5.5.x, mod_perl2, perl 5.8.8, Linux
environment, some links are being re-directed by Apache via mod_jk, to a
back-end Tomcat server, and a webapp running in that server.
For reasons that are off-topic and obscure, that webapp generates html
pages that are really encoded in iso-8859-2, but with a Content-Type
response header that says they are iso-8859-1. It's like that, and I
cannot change this at the webapp or Tomcat level, not even with a
servlet filter.
So I need to modify the Content-Type response header, after-the-fact
(meaning when the response from Tomcat has been channeled back to Apache
via mod_jk).
My first inspiration was to do it using mod_headers.
But this does not work for some reason. I have been told on either the
Apache or Tomcat forum, that it was because Apache or mod_jk does
something internally, to prevent the response headers generated by
Tomcat, to be modifiable by Apache later on.
I do not really know if that is true, but it matches the symptoms that I
am seeing : a custom HTTP header that I *add* to the response after
mod_jk shows up properly at browser level, but it conpletely ignores my
attempts at deleting/editing/replacing the Content-Type header for the
same response.
Then I found Apache2::Filter::HTTPHeadersFixup, which seems to be almost
exactly what I am looking for.
Except that I have a doubt :
HTTPHeadersFixup is a connection filter, I guess by necessity for that
kind of thing. Which means that it affects all requests that go through
that VHost. However, only a small fraction of these requests (the ones
that are re-directed to that rogue Tomcat application) should have their
response Content-Type modified, and not all requests.
So my question is, rather generally, what would be the best way to
implement what I need, either with HTTPHeadersFixup or without it ?
Here is a snippet of the configuration I have at the moment, including
what I tried with mod_headers (but which does not work) :
(lines with ### prefix are my comments to explain what it does/should do)
Start :
### set the is-jk variable only for requests that will be re-directed to
the rogue Tomcat application
SetEnvIf REQUEST_URI "/servlet\.[^\.]+$" is-jk
### if the above var is set, then try modifying the mod_jk response
header after-the-fact, at VHost level
Header always set Content-Type: "text/html; charset=ISO-8859-2" env=is-jk
### just to check the above, also add a custom header to the response,
under the same conditions
Header always set Test-Header: "VHost level" env=is-jk
### the following Location is where the mod_jk redirect really happens
(the setHandler plays the same role as a JkMount directive)
<LocationMatch "/servlet\.[^.]+$">
SetHandler jakarta-servlet
### try the same as before, but within the specific Location scope
Header always set Content-Type: "text/html; charset=ISO-8859-2"
Header always set Test-Header: "Location level"
</LocationMatch>
:End
The result of the above, is that the custom header "Test-Header" gets
indeed added to the appropriate responses, at the "Location" level (the
Location directive replaces the one generated by the generic one).
But, the Content-Type header obstinately stays at what the rogue webapp
set it, which is "Content-Type: text/html; charset=ISO-8859-1" (instead
of -2 at the end).
One of my questions is thus : assuming I keep adding this custom header
"Test-Header" via mod_headers, will it be visible by the
HTTPHeadersFixup subclass I create and configure ? if yes, I could make
a simple test in my subclass to detect if this request is indeed one
that needs to be modified. Or is there another/better/simpler way to
resolve my problem ?
And, best wishes to all for tomorrow and on.
