Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5090361A.4060609@holeczek.de>
References: 
 <CAOGo0VZv9sPbdHn+pNnszFGuTe8Q9UL6SBH6WS7ZEuW8gojBHw@mail.gmail.com>
	<5090361A.4060609@holeczek.de>
Date: Tue, 30 Oct 2012 21:29:55 +0000
Message-ID: 
 <CAOGo0Vbw42_WyJjieggQXwWfs49F+JCc7D_ei245-Jt5r3-WKw@mail.gmail.com>
Subject: Re: Content-Encoding, License for .graffle file, Was: Fwd: [VOTE]
 Release celix-0.0.1-incubating
From: sebb <sebbaz@gmail.com>
To: general@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 30 October 2012 20:18, Florian Holeczek <florian@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 conside=
r 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. Unti=
l it is fixed, I suggest adding a note to any vote e-mails to warn reviewer=
s 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 agai=
n. Although the server correctly responses with "Content-Encoding gzip", th=
e 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 f=
ormat. 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org