Re: [us...@httpd] Problem with mod_headers ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, André Warnier wrote: I am using a Tomcat java application which unfortunately sets the Content-Type response header wrongly : it says text/html; charset=iso-8859-1 instead of text/html; charset=iso-8859-2, and there is no way I can change that application itself. So I am trying to rectify that header after-the-fact, using mod_headers. Unfortunately, it does not seem to work. This obviously isn't answering your question, but isn't the application advertising ISO-8859-2 as the content type because that's what it's using? If the application can't be changed (that is, the Content-Type is set in stone somewhere) wouldn't the /actual/ encoding being used also be set in stone? What's the danger in allowing the application to simply continue to use ISO-8859-1 (other than the obvious limitations of the character set itself)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklr5I0ACgkQ9CaO5/Lv0PCt9QCfQivKj8se2vGgYt8ayOGGroMs i6sAn1UHLVPMGZXmPd+qiE3XD6ECRTgk =JhD5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, André Warnier wrote: - 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. Note that this is a very common use case for filters: wrap the request (or, in this case, the response) with a custom object that extends ServletRequestWrapper (or ServletResponseWrapper) and overrides the appropriate methods, then delegate processing to the next processor in the filter chain. You probably want to use HttpServletResponseWrapper in stead of the more generic wrapper class. (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.) That's a pretty significant bug! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklr5g4ACgkQ9CaO5/Lv0PA8sACgpmv/U0O/DsFHvow33QllQeIF VxkAoILFKW+1R1ljGegbVQAWNutNlyDE =WrCw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
André Warnier wrote: As a separate question : how does Apache (or mod_jk) exactly arrange to do that (not allow mod_headers to change the response headers set by Tomcat) ? The answer may help me decide whether I can/want to try writing my own mod_perl response header modification handler (or output filter). And as an additional comment, I do think that indeed this is debatable. After all, if the Apache admin decides to overwrite the headers set by Tomcat, it should be his (informed) decision, no ? Note: this is based on observations from Apache 1.3; Apache 2.x may well behave differently -- and even then, these are vague memories of experiments done quite a long ago. The request processing is split into different phases, and modules attach to hooks for the phases. For some phases, there can be only one module acting upon a single request (f.ex. the actual generation of the response), but for others (rewriting the request, handling headers, ...), the stage can consist of various modules that are stacked on top of each other, working in a chain. This is what makes things difficult: the various phases are not that well documented, and likewise, the module documentation does not outright tell to which processing phase(s) the module attaches itself. A final missing piece of documentation, I recall, was that the modules were inserted to the stacks in the order they were loaded (the LoadModule/UseModule statements in the configuration). So, in order to get the desired outcome of a combination of modules, you'll need to dig through them to find out to which phases they attach, and then load them in an order that is appropriate for your needs. -- ..Juha - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
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). 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[us...@httpd] Problem with mod_headers ?
Hi. The following is verbatim what I posted earlier on the Apache user's list. I am reposting it here because I did not really get a satisfactory answer on the Apache httpd list, and because I know that mod_jk experts lurk around here. And maybe this has something to do with the fact that the requests we're talking about are handled by a Tomcat webapp, after being re-directed by Apache/mod_jk. The underlying question is also : despite what I'm saying below about not being able to change the webapp (which is basically true), I think I should be able to change the Content-Type header (which I believe is generated by the rogue webapp or by Tomcat itself), *before* it gets sent back to Apache via mod_jk. And I guess that in order to do that, I would have to create a servlet filter that acts at the output level. How hard would that be to do ? (I already have a servlet filter around this webapp, but at the moment it only acts on the input side). Original message to Apache list follows : I am a bit at my wit's end here. Using Apache 2.2.3 under Suse Linux, with a mod_jk re-director to Tomcat (5.0.x) for certain links, such as the one of which question below. I am using a Tomcat java application which unfortunately sets the Content-Type response header wrongly : it says text/html; charset=iso-8859-1 instead of text/html; charset=iso-8859-2, and there is no way I can change that application itself. So I am trying to rectify that header after-the-fact, using mod_headers. Unfortunately, it does not seem to work. I have this Vhost configuration (snippet) : SetEnvIf REQUEST_URI /servlet\.[^\.]+$ is-jk Header always set Content-Type: text/html; charset=ISO-8859-2 env=is-jk Header always set Test-Header: VHost level env=is-jk LocationMatch /servlet\.[^.]+$ SetHandler jakarta-servlet Header always set Content-Type: text/html; charset=ISO-8859-2 Header always set Test-Header: Location level /LocationMatch I capture the HTTP headers resulting from a request, using the LiveHttpHeaders plugin of Firefox, as follows (sorry for the email wrap-around, and sensitive bits edited-out with XXX): POST /starweb/XXX/servlet.starweb HTTP/1.1 Host: XXX.XXX.XXX User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.15) Gecko/20080623 Firefox/2.0.0.15 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-gb,en;q=0.7,de-de;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http:///starweb/wideoteka/servlet.starweb?path=wideoteka/wideoteka-sso.webauth=y Cookie: , JSESSIONID=3AD2CE2435CDCC2CFD3C90D7DF23868B Pragma: no-cache Cache-Control: no-cache Content-Type: application/x-www-form-urlencoded Content-Length: 273 HTTP/1.x 200 OK Date: Tue, 30 Dec 2008 17:30:33 GMT Server: Apache/2.2.3 (Linux/SUSE) mod_jk/1.2.28-dev-727724 mod_perl/2.0.2 Perl/v5.8.8 Content-Type: text/html;charset=ISO-8859-1 Test-Header: Location level Expires: Mon, 26 Jul 1997 05:00:00 GMT Pragma: no-cache Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked As can be seen above, the Test-Header that I set with mod_headers comes out perfectly, from the Location section. But the Content-Type header, which I believe should be set in the same exact conditions, does not. Does anyone have an idea why ? Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
André, when using mod_jk, Apache HTTPD will not change any headers sent from Tomcat, even if you use mod_headers. Since mod_jk is delegating the whole request to Tomcat, this behaviour is expected, though debatable. Writing a filter to change your headers in Tomcat is no big deal, the link should point out the basics: http://marc.info/?l=tomcat-userm=116482946929752w=2 Cheers Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
Gregor Schneider wrote: André, when using mod_jk, Apache HTTPD will not change any headers sent from Tomcat, even if you use mod_headers. Since mod_jk is delegating the whole request to Tomcat, this behaviour is expected, though debatable. Writing a filter to change your headers in Tomcat is no big deal, the link should point out the basics: http://marc.info/?l=tomcat-userm=116482946929752w=2 Hi, and thank you for the information, and the example ref. It seems simpler than I thought. Since I already have a self-written filter around this application, I'll try to add such. My only doubt at this stage, is that if the wrapped servlet itself sets the (wrong) Content-Type header, it might overwrite the one I set before the doFilter(), no ? As a separate question : how does Apache (or mod_jk) exactly arrange to do that (not allow mod_headers to change the response headers set by Tomcat) ? The answer may help me decide whether I can/want to try writing my own mod_perl response header modification handler (or output filter). And as an additional comment, I do think that indeed this is debatable. After all, if the Apache admin decides to overwrite the headers set by Tomcat, it should be his (informed) decision, no ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [us...@httpd] Problem with mod_headers ?
Hi André, On Tue, Dec 30, 2008 at 10:25 PM, André Warnier a...@ice-sa.com wrote: My only doubt at this stage, is that if the wrapped servlet itself sets the (wrong) Content-Type header, it might overwrite the one I set before the doFilter(), no ? you might have to give it a try As a separate question : how does Apache (or mod_jk) exactly arrange to do that (not allow mod_headers to change the response headers set by Tomcat) ? The answer may help me decide whether I can/want to try writing my own mod_perl response header modification handler (or output filter). And as an additional comment, I do think that indeed this is debatable. After all, if the Apache admin decides to overwrite the headers set by Tomcat, it should be his (informed) decision, no ? well, you should discuss this with Rainer Jung - he is the maintainer of mod_jk. No idea, but maybe this behaviour is due to the specs pf the AJP13-protocoll. Cheers Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
