I believe I've just reconfigured apache to not compress .gz/.bz2 files again.  
They joy of adding compression by encoding type rather than filename.

Pat

On 05/30/2013 05:13 AM, Ansgar Hockmann-Stolle wrote:
> Maybe an issue with the web server?
>
> Downloading the file with firefox and wget will give different files:
>
> 216856 May 30 11:38 firefox/comps-sl6-x86_64.xml.gz
> 216991 Mar 22 19:10 wget/comps-sl6-x86_64.xml.gz
>
> The Apache is zipping the file on the fly again, but firefox does not unzip 
> it right:
>
> firefox/comps-sl6-x86_64.xml:    gzip compressed data, from Unix, max 
> compression
> firefox/comps-sl6-x86_64.xml.gz: gzip compressed data, from Unix
> wget/comps-sl6-x86_64.xml:       XML  document text
> wget/comps-sl6-x86_64.xml.gz:    gzip compressed data, from Unix, max 
> compression
>
> firefox/comps-sl6-x86_64.xml is the original zipped file!
>
> Sniffing while downloading with firefox:
>
>> GET /linux/scientific/6.4/x86_64/os/repodata/comps-sl6-x86_64.xml.gz HTTP/1.1
>> Host: ftp.scientificlinux.org
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 
>> Firefox/21.0
>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
>> Accept-Encoding: gzip, deflate
>> Referer: 
>> http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/repodata/
>> Connection: keep-alive
>> Pragma: no-cache
>> Cache-Control: no-cache
>>
>> HTTP/1.1 200 OK
>> Date: Thu, 30 May 2013 09:38:04 GMT
>> Server: Apache
>> Last-Modified: Fri, 22 Mar 2013 18:10:26 GMT
>> ETag: "3fa15b6f-34f9f-4d8875e974880"
>> Accept-Ranges: bytes
>> Vary: Accept-Encoding
>> Content-Encoding: gzip
>> Content-Security-Policy: default-src 'self'; style-src 'self' unsafe-inline;
>> X-Content-Security-Policy: allow 'self'; default-src 'self'; style-src 
>> 'self' unsafe-inline;
>> Keep-Alive: timeout=3, max=200
>> Connection: Keep-Alive
>> Transfer-Encoding: chunked
>> Content-Type: application/x-gzip
>>
>> 1faa
> [...]
>
> Sniffing while downloading with wget:
>
>> GET /linux/scientific/6.4/x86_64/os/repodata/comps-sl6-x86_64.xml.gz HTTP/1.1
>> User-Agent: Wget/ (linux-gnu)
>> Accept: */*
>> Host: ftp.scientificlinux.org
>> Connection: Keep-Alive
>>
>> HTTP/1.1 200 OK
>> Date: Thu, 30 May 2013 09:49:27 GMT
>> Server: Apache
>> Last-Modified: Fri, 22 Mar 2013 18:10:26 GMT
>> ETag: "3fa15b6f-34f9f-4d8875e974880"
>> Accept-Ranges: bytes
>> Content-Length: 216991
>> Vary: Accept-Encoding
>> Content-Security-Policy: default-src 'self'; style-src 'self' unsafe-inline;
>> X-Content-Security-Policy: allow 'self'; default-src 'self'; style-src 
>> 'self' unsafe-inline;
>> Keep-Alive: timeout=3, max=200
>> Connection: Keep-Alive
>> Content-Type: application/x-gzip
>>
>> ^_213^H^@^@^@^@^@^B^C254Z333s333֙^?357_qV/j247U330vvgvv\v353244333d266323355244
> [...]
>
> I think apache should be configured not to zip already zipped files.
>
> Ciao
>     Ansgar
>
>
> Am 28.05.2013 17:25, schrieb Pat Riehecky:
>> When I run less on the file, it show the text as expected.
>>
>> Spacewalk is not really my area of expertise....  is your Spacewalk
>> server fully updated?
>>
>> Pat
>>
>> On 05/28/2013 10:16 AM, Paul Robert Marino wrote:
>>> I downloaded it with wget and used the less command on it.
>>> sure enough when i use cat on it it returns binary data but it still
>>> doesn't explain why this only happens with scientific Linux repos. Im
>>> wondering if its because there is both a comps-sl6-x86_64.xml.gz and a
>>> comps-sl6-x86_64.xml file in the repo. or if spacewalk is complaining
>>> about an other file the error is somewhat vague the only reason I
>>> thought the comps file might be the issue is because its mentioned
>>> right before the error.
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 10:31 AM, Pat Riehecky <[log in to unmask]
>>> <mailto:[log in to unmask]>> wrote:
>>>
>>>     On 05/28/2013 09:19 AM, Paul Robert Marino wrote:
>>>>     Hello
>>>>     I have been having issues with spacewalk and Scientific Linux 6.4
>>>>     and 6 rolling repos
>>>>     after investigation I found 2 errors
>>>>     first
>>>>     "
>>>>     Repo
>>>> http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/
>>>>     has comps file comps-sl6-x86_64.xml.gz.
>>>>     ERROR: Not a gzipped file
>>>>     "
>>>>
>>>>     The second is spacewalk 1.8 doesn't handle the error gracefully
>>>>     but version 1.9 does.
>>>>     note version 1.8 does not produce the "ERROR: Not a gzipped file"
>>>>     instead it does a trace back about an unknown error code.
>>>>
>>>>     Ive checked
>>>> http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/repodata/comps-sl6-x86_64.xml.gz
>>>>     and been able to confirm that indeed it is not gziped this should
>>>>     be corrected in whatever script is generating it.
>>>>
>>>>     Thank You
>>>>     Paul Robert Marino
>>>
>>>     Thanks for the report,
>>>
>>>     The comps.xml files for SL6.4 were compressed with zopfli in gzip
>>>     compatibility mode.  This resulted in a 11% size savings on my
>>>     limited testing.
>>>
>>>     They decompress correctly with gzip (just tested again)
>>>
>>>     $ gzip -dc comps-sl6-x86_64.xml.gz |wc -l
>>>     16830
>>>
>>>     and they are correctly identified by 'file' as being gzip
>>>     compressed data.
>>>
>>>     $ file comps-sl6-x86_64.xml.gz
>>>     comps-sl6-x86_64.xml.gz: gzip compressed data, from Unix, max
>>>     compression
>>>
>>>     How did you check the comps-sl6-x86_64.xml.gz file that it
>>>     reported as a non-gzip file?
>>>
>>>     Pat
>>>
>>>     --
>>>     Pat Riehecky
>>>
>>>     Scientific Linux developer
>>>     http://www.scientificlinux.org/
>>>
>>>
>>
>>
>> -- 
>> Pat Riehecky
>>
>> Scientific Linux developer
>> http://www.scientificlinux.org/
>>
>
>


-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/