Re: [xwiki-devs] attachment's mime-types

I wish you were right and it would be configurable by the tomcat but it's not the case. The same tomcat serves: http://i2geo.net/files/movies/index.htm with: Content-Type: text/html; charset=utf-8 so you are saying you can't do anything against it?

Le 04-oct.-09 à 04:08, Sergiu Dumitriu a écrit : > Paul Libbrecht wrote: >> Unfortunately, none of the below suggestions have helped. >> Note, contrary to the mails of Jerome and Niels below, it's about the >> /download/ action here. >> >> I still get this with Curriki 1.8 branch (based on xwiki 1.8). >> This now breaks at least one user. >> >> Since there's no single possible thinkable way of knowing the character >> set of an attachment unless reading it, I insist it is a bug to add this >> charset to the header! >> >> So guys, any way to remove this addition? >> > > It's added automatically. If we do: > > response.setContentType("application/octet-stream"), the container adds > automatically the charset, and I think that this explains the behavior: > > http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletResponse… > > > "The charset for the MIME body response can be specified with > setContentType(java.lang.String). For example, "text/html; > charset=Shift_JIS". The charset can alternately be set using > setLocale(java.util.Locale). If no charset is specified, ISO-8859-1 will > be used." > > I think the only way to get rid of it is to provide your own > implementation of the ServletResponse class... > >> >> Le 17-mars-09 à 13:42, Niels Mayer a écrit : >> >>> 2008/12/28 Paul Libbrecht &lt;paul(a)activemath.org&gt; >>> can someone explain me what is the strategy to define the mime-type of >>> an attachment? >>> I see not configurable map nor any setter on the attachment types. >>> Is there any way I can enrich this or is it simply taking over the >>> mime-type provided the browser (which, too often, ends up being >>> application/octet-stream) ? >>> ... [sergiu suggests "web.xml. Search for css, and do something >>> similar for your mimetypes."] ... >>> worked well to one point: the mime-type is added with a charset >>> parameter which is even iso-8859-1 although everything in my >>> environment is set to be utf-8. >>> >>> Do I have a way to remove that charset for such downloads? >>> That would be the most sensible one. >>> >>> Perhaps this is relevant: >>> to jerome(a)xwiki.com, XWiki Users &lt;users(a)xwiki.org&gt; >>> date Fri, Mar 13, 2009 at 5:48 PM >>> subject Re: [xwiki-users] [xwiki-devs] support for google sitemaps >>> and webmaster tools? (and why do xwiki RDF's give "unsupported file >>> format"?) >>> >>> ... >>> >>> No matter what I did in my setup, I was getting >>> >>> <?xml version="1.0" encoding="ISO-8859-1" ?> >>> >>> The roller blog atom feed that *does* work correctly w/ google sitemaps >>> returns: >>> <?xml version="1.0" encoding='utf-8'?> >>> >>> I fixed this issue by running java with -Dfile.encoding=UTF-8 (note >>> the lowercase setting suggested in >>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances seems >>> incorrect?). When that alone didn't work, I also added >>> "-Djavax.servlet.request.encoding=UTF-8-DjavaEncoding=UTF-8" which had >>> been suggested in solving this problem for other Tomcat users. >>> (Now I run java with the following options:-server -Xms160m -Xmx1024m >>> -XX:PermSize=160m -XX:MaxPermSize=320m >>> -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8 >>> -DjavaEncoding=UTF-8 -Djava.awt.headless=true) >>> >>> I also saw other suggestions to set LANG="en_US.UTF-8" in the tomcat >>> launching script... however, I'm not sure which of my changes "did" >>> it, but i believe that following two steps I'd forgotten||skipped in >>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Encoding caused >>> the correct encoding to be used: >>> (1) WEB-INF> diff web.xml.~1~ web.xml >>> 23c23 >>> < <param-value>ISO-8859-1</param-value> >>> --- >>>> <param-value>UTF-8</param-value> >>> (2) WEB-INF> diff xwiki.cfg.~2~ xwiki.cfg >>> 29c29 >>> < xwiki.encoding=ISO-8859-1 >>> --- >>>> xwiki.encoding=UTF-8 >>> >>> With all of the above now reconfigured, I now get the correct output >>> for http://nielsmayer.com/xwiki/bin/view/Main/WebRss?xpage=rdf : >>> <?xml version="1.0" encoding="UTF-8" ?> >>> >>> ... >>> -- Niels >>> http://nielsmayer.com >>> >>> PS: Why not just have xwiki.cfg's default be: 'xwiki.encoding=UTF-8' ; >>> likewise have web.xml's default for >>> com.xpn.xwiki.web.SetCharacterEncodingFilter's 'encoding' be UTF-8. >>> These encoding errors that oft go unnoticed are probably resulting in >>> a number of configuration errors, and perhaps other bug-reports that >>> aren't entirely valid, should they depend on encoding issues.