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/