Re: Content-Encoding, License for .graffle file, Was: Fwd: [VOTE] Release celix-0.0.1-incubating
Hi, 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. I agree that the download problem is not a blocker for the release. Until it is fixed, I suggest adding a note to any vote e-mails to warn reviewers about the problen. Using wget, I was able to download the archive, sig and hashes. 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 -- Met vriendelijke groet, Alexander Broekhuis
Re: Content-Encoding, License for .graffle file, Was: Fwd: [VOTE] Release celix-0.0.1-incubating
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
Re: Content-Encoding, License for .graffle file, Was: Fwd: [VOTE] Release celix-0.0.1-incubating
On 30 October 2012 20:18, Florian Holeczek flor...@holeczek.de wrote: Hi all, taking this out of the Celix vote thread in order to keep it tidy. Sebb wrote: The file documents/Celix.graffle does not have a license. 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. I agree that the download problem is not a blocker for the release. Until it is fixed, I suggest adding a note to any vote e-mails to warn reviewers about the problen. Using wget, I was able to download the archive, sig and hashes. 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 www.apache.org does not gzip-encode the response even if requested, which is why the browsers work OK there. However, I suppose some mirrors might behave differently. The problem is that many browsers and other clients don't handle Content-Encoding gzip correctly. The curl program has a --compress option which requests gzip and handles the response, but even that fails to handle CE: gzip if requested using -H Accept-Encoding: gzip. Oops! Regards Florian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
