The same tomcat serves:
http://i2geo.net/files/movies/index.htmwith: Content-Type: text/html; charset=utf-8 so you are saying you can't do anything against it? paul 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 thischarset 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.html "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 usingsetLocale(java.util.Locale). If no charset is specified, ISO-8859-1 willbe 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 <[email protected]>can someone explain me what is the strategy to define the mime- type ofan 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 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 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 inhttp://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances seemsincorrect?). When that alone didn't work, I also added"-Djavax.servlet.request.encoding=UTF-8-DjavaEncoding=UTF-8" which hadbeen 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 ina number of configuration errors, and perhaps other bug-reports that aren't entirely valid, should they depend on encoding issues.-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
