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?

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.

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.

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

It's added automatically. If we do: response.setContentType("application/octet-stream"),