Bug 118410 - up2date do not handle HTTP error codes properly
Summary: up2date do not handle HTTP error codes properly
Keywords:
Status: CLOSED DUPLICATE of bug 116479
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC2Target up2date-fc2 FC3Target FC4Target
TreeView+ depends on / blocked
 
Reported: 2004-03-16 14:53 UTC by Leonid Kanter
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-27 16:08:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Leonid Kanter 2004-03-16 14:53:19 UTC
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 14:55:54 UTC
Sorry, I pasted 404 error in wrong place, but the idea must be clear.

Comment 2 Adrian Likins 2004-03-22 21:12:59 UTC
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 14:36:02 UTC
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 16:08:18 UTC

*** 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.