> > 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
