Hi Alexander, Alexander Broekhuis wrote: >> In JSPWiki, we have a .graffle file, too. Although this is XML, I consider >> this a binary file, just like a JPEG image for example. It's the document >> format of Graffle, a graphics software for Mac OS X. > > In the Celix case the file can/should be removed. But otherwise, it being a > file created by a tool, a NOTE or README file can be used to "set" the > license. Celix uses this to clearify the license information on some input > files which are processed during the build.
thanks for the details. I'll remove it from the JSPWiki artifacts then, too. >> The problem underneath is: When the browser tells "Accept-Encoding gzip" >> in its HTTP request header, it can be that a .gz download gets gzipped >> again. Although the server correctly responses with "Content-Encoding >> gzip", the browser may not handle this download correctly and save it >> double gzipped to disk. So you end up with a file .tar.gz which in fact is >> a .tar.gz.gz format. Gunzipping this manually leads to the correct data. >> So, >> * there isn't any real data corruption and >> * it seems to be at least not only the server part which is to blame here > > This is what I noticed as well. It seems more likely that the browser does > something wrong here. Looking at the headers I couldn't find anything > strange. Funny thing is, for Chrome a bug has been solved to strip an extra > gz from downloaded files: [1] > > [1]: http://code.google.com/p/chromium/issues/detail?id=58168 Bugzilla entries are existing for Firefox, too, but they're not resolved yet. See [1] for example. Regards Florian [1] https://bugzilla.mozilla.org/show_bug.cgi?id=610679 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
