Re: DefaultServlet and default character encoding
On Thu, 17 Jun 2010 19:32:36 +0400, Konstantin Kolinko knst.koli...@gmail.com wrote: 2010/6/17 Felix Schumacher felix.schumac...@internetallee.de: For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. I know that setting charset in a mime-mapping works, e.g.: mime-mapping extensionhtm/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping mime-mapping extensionhtml/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping Note, that it would be better if the mime type set by a HTTP header and the one provided by HTML tag match strictly (case sensitively). Otherwise some browsers will start guessing. IIRC, the HTML spec says that the HTTP header takes precedence, but not all browsers follow it strictly. I will look into this one. Also there is AddDefaultCharsetFilter in Tomcat 7. It is similar to what you are doing, see its JavaDoc and source code. Yes, my filter looked like a twin, with the exception, that I called super.setCharacterEncoding(defaultEncoding) instead of manipulating the content-type directly (and of course that defaultEncoding is different to super.getCharacterEncoding() which would yield iso-8859-1). I could extend that filter to my needs. Should I file a enhancement request for that? apache httpd thinks it would be better to append a charset to the response I wonder, if there is a way to improve your Apache HTTPD configuration. I tried to let apache httpd now that in location /webapp the default charset was different from iso-8859-1. But mod_jk ignored my pledges :( Even so I think DefaultServlet should be able to set a charset if configured to. Bye Felix Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet and default character encoding
On 18.06.2010 11:04, Felix Schumacher wrote: On Thu, 17 Jun 2010 19:32:36 +0400, Konstantin Kolinko knst.koli...@gmail.com wrote: 2010/6/17 Felix Schumacherfelix.schumac...@internetallee.de: For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. I know that setting charset in a mime-mapping works, e.g.: mime-mapping extensionhtm/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping mime-mapping extensionhtml/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping Note, that it would be better if the mime type set by a HTTP header and the one provided by HTML tag match strictly (case sensitively). Otherwise some browsers will start guessing. IIRC, the HTML spec says that the HTTP header takes precedence, but not all browsers follow it strictly. I will look into this one. Also there is AddDefaultCharsetFilter in Tomcat 7. It is similar to what you are doing, see its JavaDoc and source code. Yes, my filter looked like a twin, with the exception, that I called super.setCharacterEncoding(defaultEncoding) instead of manipulating the content-type directly (and of course that defaultEncoding is different to super.getCharacterEncoding() which would yield iso-8859-1). I could extend that filter to my needs. Should I file a enhancement request for that? apache httpd thinks it would be better to append a charset to the response I wonder, if there is a way to improve your Apache HTTPD configuration. I tried to let apache httpd now that in location /webapp the default charset was different from iso-8859-1. But mod_jk ignored my pledges :( Even so I think DefaultServlet should be able to set a charset if configured to. How did you do that in Apache? Did you use http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset and if so, how exactly? You can switch JkLogLevel on a system with low load to debug, then mod_jk will log all response headers it received from Tomcat. mod_jk itself takes the Content-Type header received from tomcat, extracts its full value and applies it to the Apache response via ap_set_content_type(). Apache later applies any configured default charset via ap_http_header_filter() in ap_http_header_filter(). At least that's what I expect to happen. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet and default character encoding
On Fri, 18 Jun 2010 12:50:31 +0200, Rainer Jung rainer.j...@kippdata.de wrote: On 18.06.2010 11:04, Felix Schumacher wrote: On Thu, 17 Jun 2010 19:32:36 +0400, Konstantin Kolinko knst.koli...@gmail.com wrote: 2010/6/17 Felix Schumacherfelix.schumac...@internetallee.de: For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. I know that setting charset in a mime-mapping works, e.g.: mime-mapping extensionhtm/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping mime-mapping extensionhtml/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping Note, that it would be better if the mime type set by a HTTP header and the one provided by HTML tag match strictly (case sensitively). Otherwise some browsers will start guessing. IIRC, the HTML spec says that the HTTP header takes precedence, but not all browsers follow it strictly. I will look into this one. Also there is AddDefaultCharsetFilter in Tomcat 7. It is similar to what you are doing, see its JavaDoc and source code. Yes, my filter looked like a twin, with the exception, that I called super.setCharacterEncoding(defaultEncoding) instead of manipulating the content-type directly (and of course that defaultEncoding is different to super.getCharacterEncoding() which would yield iso-8859-1). I could extend that filter to my needs. Should I file a enhancement request for that? apache httpd thinks it would be better to append a charset to the response I wonder, if there is a way to improve your Apache HTTPD configuration. I tried to let apache httpd now that in location /webapp the default charset was different from iso-8859-1. But mod_jk ignored my pledges :( Even so I think DefaultServlet should be able to set a charset if configured to. How did you do that in Apache? Did you use http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset and if so, how exactly? I placed the following into the config for the corresponding virtual host: Location /webapp AddDefaultCharset utf-8 /Location Yesterday after restart of httpd I found no difference in behaviour... Now the directive does work as expected. So mod_jk/httpd can be configured to work around the issue. Maybe I saw an old page from some sort of cache/proxy :( Grüße Felix You can switch JkLogLevel on a system with low load to debug, then mod_jk will log all response headers it received from Tomcat. mod_jk itself takes the Content-Type header received from tomcat, extracts its full value and applies it to the Apache response via ap_set_content_type(). Apache later applies any configured default charset via ap_http_header_filter() in ap_http_header_filter(). At least that's what I expect to happen. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet and default character encoding
On 18.06.2010 13:50, Felix Schumacher wrote: On Fri, 18 Jun 2010 12:50:31 +0200, Rainer Jungrainer.j...@kippdata.de wrote: On 18.06.2010 11:04, Felix Schumacher wrote: On Thu, 17 Jun 2010 19:32:36 +0400, Konstantin Kolinko knst.koli...@gmail.com wrote: 2010/6/17 Felix Schumacherfelix.schumac...@internetallee.de: apache httpd thinks it would be better to append a charset to the response I wonder, if there is a way to improve your Apache HTTPD configuration. I tried to let apache httpd now that in location /webapp the default charset was different from iso-8859-1. But mod_jk ignored my pledges :( Even so I think DefaultServlet should be able to set a charset if configured to. How did you do that in Apache? Did you use http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset and if so, how exactly? I placed the following into the config for the corresponding virtual host: Location /webapp AddDefaultCharset utf-8 /Location Yesterday after restart of httpd I found no difference in behaviour... Now the directive does work as expected. So mod_jk/httpd can be configured to work around the issue. Maybe I saw an old page from some sort of cache/proxy :( Good to know. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
DefaultServlet and default character encoding
Hi, I have a character encoding problem with the DefaultServlet. We use it to serve static html content, which is encoded in utf-8. The DefaultServlet doesn't set characterset in the response, so the browser looks for a meta-tag describing the encoding. Luckily these are set in our content and the content is displayed correctly. So no problem... ...but if we have the same application behind an apache httpd-server connected with mod_jk, apache httpd thinks it would be better to append a charset to the response. In our case it takes a guess ( I guess ) and appends iso-8859-1 to the content-type header. Which in turn renders the meta-tag inside of the html useless and results in a wrong encoding/display in the browser. I have found an old discussion on this list where this problem was discussed (without the mod_jk part) http://old.nabble.com/DefaultServlet-doesn%27t-set-charset-td18893115.html#a18929527 My Question now is, should I file a bug to enhance DefaultServlet? If so would it be legal to include the patch from that discussion? For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. Bye Felix - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet and default character encoding
On 17/06/2010 15:23, Felix Schumacher wrote: My Question now is, should I file a bug to enhance DefaultServlet? If so would it be legal to include the patch from that discussion? That is covered by section 5 of the ALv2, so yes it would be legal. Make sure you correctly attribute it. I'd add the link, not the actual patch. Whilst this would be legal the ASF normally goes further and only includes patches that were intentionally contributed. Even if we legally could, we don't want to use someones code of they don't want us to. In this case - having read the thread - I would say that it was definitely a contribution so would have no problem applying the patch. I would add that if the patch had been added to a new bugzilla item, there is a good chance it would be in the code base already. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DefaultServlet and default character encoding
2010/6/17 Felix Schumacher felix.schumac...@internetallee.de: For the moment I have written a filter, which sets a default encoding, as soon as Response.setContentType(String type) is called and type.startsWith(text/). That works for the moment, but I would prefer the solution described in above thread. I know that setting charset in a mime-mapping works, e.g.: mime-mapping extensionhtm/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping mime-mapping extensionhtml/extension mime-typetext/html;charset=iso-8859-1/mime-type /mime-mapping Note, that it would be better if the mime type set by a HTTP header and the one provided by HTML tag match strictly (case sensitively). Otherwise some browsers will start guessing. IIRC, the HTML spec says that the HTTP header takes precedence, but not all browsers follow it strictly. Also there is AddDefaultCharsetFilter in Tomcat 7. It is similar to what you are doing, see its JavaDoc and source code. apache httpd thinks it would be better to append a charset to the response I wonder, if there is a way to improve your Apache HTTPD configuration. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
