Bug 118410 - up2date do not handle HTTP error codes properly
up2date do not handle HTTP error codes properly
Status: CLOSED DUPLICATE of bug 116479
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
:
Depends On:
Blocks: FC2Target up2date-fc2 FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-03-16 09:53 EST by Leonid Kanter
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-27 12:08:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Leonid Kanter 2004-03-16 09:53:19 EST
Description of problem:

If a header file is absent on server (for example, server is not in
sync yet), up2date is trying to gunzip text of servers's 404 eroor
text (!) and than falling down with traceback "data is not in gzip
format" or something like this. Right now it can be reproduced with
fedora-devel on mirrors.kernel.org. HTTP codes must be parsed before
sending data to gunzip function.

Version-Release number of selected component (if applicable):

up2date-4.3.11-2.1.1

How reproducible:

always

Traceback:


[root@localhost root]# up2date 
Traceback (most recent call last): 
 File "/usr/share/rhn/up2date_client/gui.py", line 1360, in
onChannelsPageNext 
   self.pkgList = self.pList.getPackagesToInstall() 
 File "/usr/share/rhn/up2date_client/packageList.py", line 580, in
getPackagesToInstall 
   result = self.__skipPackages(result) 
 File "/usr/share/rhn/up2date_client/packageList.py", line 609, in
__skipPackages 
   packageList = self.__skipFiles(packageList) 
 File "/usr/share/rhn/up2date_client/packageList.py", line 630, in
__skipFiles 
   ignoreMsgCallback = self.ignoreMsgCallback) 
 File "/usr/share/rhn/up2date_client/packageList.py", line 669, in
buildHeaderList 
   hdr = headerList[pkg] 
 File "/usr/share/rhn/up2date_client/headers.py", line 37, in __getitem__ 
   self.__retrievePackage(item) 
 File "/usr/share/rhn/up2date_client/headers.py", line 42, in
__retrievePackage    hdr, sourceType =
rpcServer.doCall(self.repos.getHeader, item) 
 File "/usr/share/rhn/up2date_client/rpcServer.py", line 112, in doCall 
   ret = apply(method, args, kwargs) 
 File "/usr/share/rhn/up2date_client/repoDirector.py", line 31, in
getHeader 
   return self.handlers[channel['type']].getHeader(pkg, msgCallback,
progressCallback) 
 File "/usr/share/rhn/up2date_client/rpmSource.py", line 210, in
getHeader 
   header = source.getHeader(pkg, progressCallback = progressCallback) 
 File "/usr/share/rhn/up2date_client/repoBackends/yumRepo.py", line
93, in getHeader 
   hdrBuf = fh.read() 
 File "/usr/lib/python2.3/gzip.py", line 217, in read 


Here is data which it tried to gunzip:

[root@localhost root]# cat /tmp/tmp-2RGi7.hdr 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> 
<HTML><HEAD> 
<TITLE>404 Not Found</TITLE> 
</HEAD><BODY> 
<H1>Not Found</H1> 
The requested URL
/pub/fedora/linux/core/development/i386/headers/yelp-0-2.5.90-1.i386.hdr
was not found on this server.<P> 
<P>Additionally, a 404 Not Found 
error was encountered while trying to use an ErrorDocument to handle
the request. 
</BODY></HTML> 
   self._read(readsize) 
 File "/usr/lib/python2.3/gzip.py", line 260, in _read 
   self._read_gzip_header() 
 File "/usr/lib/python2.3/gzip.py", line 161, in _read_gzip_header 
   raise IOError, 'Not a gzipped file' 
IOError: Not a gzipped file 
Traceback (most recent call last): 
 File "/usr/share/rhn/up2date_client/gui.py", line 1439, in
onSkippedPagePrepare 
   maxlength = max(map(lambda x: len(x[0][0]), self.skipPkgList)) * 8 
ValueError: min() or max() arg is an empty sequence
Comment 1 Leonid Kanter 2004-03-16 09:55:54 EST
Sorry, I pasted 404 error in wrong place, but the idea must be clear.
Comment 2 Adrian Likins 2004-03-22 16:12:59 EST
Could you verify that the server actually responded with a
404 error code? 

These days it seems pretty typical to redirect errors to
a 404 page, but that page itself returns a 200 error. Needless
to say, this is incorrect behaviour and causes some problems. 
Comment 3 Eugene Kanter 2004-03-23 09:36:02 EST
wget on the same URL reported 404. I was using mirrors.kernel.org. If 
someone has full private yum repository it is very easy to test. 
Temporarily modify header.info file - corrupt any file name, then run 
up2date.
Comment 4 Rahul Sundaram 2005-06-27 12:08:18 EDT

*** This bug has been marked as a duplicate of 116479 ***

Note You need to log in before you can comment on or make changes to this bug.