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? paul Le 17-mars-09 à 13:42, Niels Mayer a écrit :
2008/12/28 Paul Libbrecht <[email protected]>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 [email protected], XWiki Users <[email protected]> date Fri, Mar 13, 2009 at 5:48 PMsubject 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 sitemapsreturns: <?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-8With 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.comPS: 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
