Re: Tomcat 7 faces servlet encoding issue
honyk wrote: Thanks for that hint. http://drifted.in/encoding/encoding.svg returns HTTP Content-type image/svg+xml (according to Firebug) but http://drifted.in/encoding/faces/encoding.svg returns image/svg+xml;charset=ISO-8859-1 In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. 1) What encoding is specified in header in the svg file? UTF-8 2) I suspect that you are using getWriter() to write the file somewhere. That will add encoding to the content type if you are running Tomcat 7, I suspect Mojarra from that or Faces Servlet respectively. They process all the requests with that 'faces' URL fragment. and IIRC you wil also observe this if you are running Tomcat 6 with *.STRICT_SERVLET_COMPLIANCE system property set to "true". You are right! So it explains the 6 vs. 7 difference ! I am just thinking where to specify that encoding for standalone SVG files. In web.xml? It can be done in mime type mapping in web.xml I've tried to change the svg mime spec to svg image/svg+xml;charset=UTF-8 and voila, it works! (not uploaded to the server yet) So it is not definitely a Tomcat issue. That seems to me like a heavy-handed fix. It may work in this case, but it would break if there ever is a SVG file with an encoding different from UTF-8. Or is that not possible ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 faces servlet encoding issue
> > Thanks for that hint. > > http://drifted.in/encoding/encoding.svg returns HTTP Content-type > > image/svg+xml (according to Firebug) > > but http://drifted.in/encoding/faces/encoding.svg returns > > image/svg+xml;charset=ISO-8859-1 > > > > In Tomcat 6 powered web I am getting just 'image/svg+xml' in both > cases. > 1) What encoding is specified in header in the svg file? UTF-8 > 2) I suspect that you are using getWriter() to write the file > somewhere. That will add encoding to the content type if you are > running Tomcat 7, I suspect Mojarra from that or Faces Servlet respectively. They process all the requests with that 'faces' URL fragment. > and IIRC you wil also observe this if you are running Tomcat 6 with > *.STRICT_SERVLET_COMPLIANCE system property set to "true". You are right! So it explains the 6 vs. 7 difference ! > > I am just thinking where to specify that encoding for > > standalone SVG files. In web.xml? > > It can be done in mime type mapping in web.xml I've tried to change the svg mime spec to svg image/svg+xml;charset=UTF-8 and voila, it works! (not uploaded to the server yet) So it is not definitely a Tomcat issue. Thanks a lot for your help! Regards, Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 faces servlet encoding issue
2011/7/30 honyk : >> > In tomcat 6 there is no difference between these two links >> > http://drifted.in/encoding/encoding.svg >> > http://drifted.in/encoding/faces/encoding.svg >> > >> > but in Tomcat 7 I am getting different results. The first is Ok while >> > the second, processed by faces servlet, breaks the encoding. > >> You have to examine what is actually is being sent to the browser. >> (The actual content of the stream and any HTTP headers that come with >> it). > > Thanks for that hint. > http://drifted.in/encoding/encoding.svg returns HTTP Content-type > image/svg+xml (according to Firebug) > but http://drifted.in/encoding/faces/encoding.svg returns > image/svg+xml;charset=ISO-8859-1 > > In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. > >> There are many ways how the things might break, but you are not saying >> what is "break" for you - what you are actually observing. > > http://drifted.in/encoding/faces/index.xhtml - both HTML and SVG texts > should match > Now I see the Content-type of that HTML page is text/html;charset=UTF-8 > while that SVG in it is image/svg+xml;charset=ISO-8859-1 > 1) What encoding is specified in header in the svg file? 2) I suspect that you are using getWriter() to write the file somewhere. That will add encoding to the content type if you are running Tomcat 7, and IIRC you wil also observe this if you are running Tomcat 6 with *.STRICT_SERVLET_COMPLIANCE system property set to "true". Maybe there is a filter that does getWriter(), or you are serving the file not as a whole response, but with include() call (like jsp:include action in JSPs). >> Are both Tomcats on the same system? Maybe your system encoding is >> different? > > It has been tested on my PC initially (Win7/64bit), but the same result I am > getting now on Linux Debian (hosted site). > >> What component writes the svg file to the response stream, and how it >> does that? > > In this test case the SVG file is static, just included in WAR. So, is it directly served by Tomcat's DefaultServlet? > So Tomcat 7 seem to be maybe too active with adding that encoding when not > it is not specified. I am just thinking where to specify that encoding for > standalone SVG files. In web.xml? It can be done in mime type mapping in web.xml Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 faces servlet encoding issue
> > In tomcat 6 there is no difference between these two links > > http://drifted.in/encoding/encoding.svg > > http://drifted.in/encoding/faces/encoding.svg > > > > but in Tomcat 7 I am getting different results. The first is Ok while > > the second, processed by faces servlet, breaks the encoding. > You have to examine what is actually is being sent to the browser. > (The actual content of the stream and any HTTP headers that come with > it). Thanks for that hint. http://drifted.in/encoding/encoding.svg returns HTTP Content-type image/svg+xml (according to Firebug) but http://drifted.in/encoding/faces/encoding.svg returns image/svg+xml;charset=ISO-8859-1 In Tomcat 6 powered web I am getting just 'image/svg+xml' in both cases. > There are many ways how the things might break, but you are not saying > what is "break" for you - what you are actually observing. http://drifted.in/encoding/faces/index.xhtml - both HTML and SVG texts should match Now I see the Content-type of that HTML page is text/html;charset=UTF-8 while that SVG in it is image/svg+xml;charset=ISO-8859-1 > Are both Tomcats on the same system? Maybe your system encoding is > different? It has been tested on my PC initially (Win7/64bit), but the same result I am getting now on Linux Debian (hosted site). > What component writes the svg file to the response stream, and how it > does that? In this test case the SVG file is static, just included in WAR. So Tomcat 7 seem to be maybe too active with adding that encoding when not it is not specified. I am just thinking where to specify that encoding for standalone SVG files. In web.xml? Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 faces servlet encoding issue
2011/7/30 honyk : > Hello Everyone, > > when migrating my JSF 2.0 app from tomcat 6.0.32 to the version 7.0.19 I've > encountered the following encoding issue. > > I have a simple JSF (xhtml) page with an embedded SVG image in it type="image/svg+xml" data="encoding.svg">. In the web.xml file there is a > faces servlet mapping set to the '/faces' path fragment. > > In tomcat 6 there is no difference between these two links > http://drifted.in/encoding/encoding.svg > http://drifted.in/encoding/faces/encoding.svg > > but in Tomcat 7 I am getting different results. The first is Ok while the > second, processed by faces servlet, breaks the encoding. > > Together with my app I ship JSTL 1.1 and Mojarra 2.0.6 (jsf-api & jsf-impl) > libraries. > > Is there necessary to set something else in my app to get the same (correct) > result also in Tomcat 7? > > I haven't found anything related here: > http://wiki.apache.org/tomcat/FAQ/CharacterEncoding > > Any idea? > You have to examine what is actually is being sent to the browser. (The actual content of the stream and any HTTP headers that come with it). There are many ways how the things might break, but you are not saying what is "break" for you - what you are actually observing. Are both Tomcats on the same system? Maybe your system encoding is different? What component writes the svg file to the response stream, and how it does that? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7 faces servlet encoding issue
Hello Everyone, when migrating my JSF 2.0 app from tomcat 6.0.32 to the version 7.0.19 I've encountered the following encoding issue. I have a simple JSF (xhtml) page with an embedded SVG image in it . In the web.xml file there is a faces servlet mapping set to the '/faces' path fragment. In tomcat 6 there is no difference between these two links http://drifted.in/encoding/encoding.svg http://drifted.in/encoding/faces/encoding.svg but in Tomcat 7 I am getting different results. The first is Ok while the second, processed by faces servlet, breaks the encoding. Together with my app I ship JSTL 1.1 and Mojarra 2.0.6 (jsf-api & jsf-impl) libraries. Is there necessary to set something else in my app to get the same (correct) result also in Tomcat 7? I haven't found anything related here: http://wiki.apache.org/tomcat/FAQ/CharacterEncoding Any idea? Regards, Jan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
