incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <>
Subject Re: Content-Encoding, License for .graffle file, Was: Fwd: [VOTE] Release celix-0.0.1-incubating
Date Tue, 30 Oct 2012 20:29:39 GMT

> 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]


Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message