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 <?xml> 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
> <mime-mapping>
> <extension>svg</extension>
> <mime-type>image/svg+xml;charset=UTF-8</mime-type>
> </mime-mapping>
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|