incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Holeczek <>
Subject Re: Content-Encoding, License for .graffle file, Was: Fwd: [VOTE] Release celix-0.0.1-incubating
Date Tue, 30 Oct 2012 20:56:19 GMT
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]:

Bugzilla entries are existing for Firefox, too, but they're not resolved yet. See [1] for



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message