Bug 249710

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Description of problem:
If you download rpm from proxy custom channel, yum request headers of that
package and will download whole file (0-*end*).
Proxy return whole file and yum-rhn-plugin will try parse this whole file as
header, which will fail.

Version-Release number of selected component (if applicable):
yum-rhn-plugin-0.4.3-2.el5

How reproducible:
always

Steps to Reproduce:
1. see #4 of BZ 247327
2. make sure you apply patch from #9 of BZ 247327
3. register RHEL5 machine to that proxy
4. yum install <package you put in custom channel in step 1>
  

I seems that the bug is not in yum rhn plugin. 
Problem is that in /var/cache/yum/msuchy-5server/primary.xml.gz is:
<rpm:header-range start="0" end="117644" />
so yum-rhn-plugin do as told.
This values should be filled. Probably by rhn-package-manager. Gonna try to
confirm it.

Even with correct header_start and header_end (see BZ 249832), yum still shout.
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for Global_File_System-as-IN to pack into transaction set.
dbg:http://proxy-test.englab.brq.redhat.com/XMLRPC/GET-REQ/msuchy-5server/getPackage/Global_File_System-as-IN-5.0.0-4.noarch.rpm
dbg:range - 440, 12984

dbg:filename
//var/cache/yum/msuchy-5server/headers/Global_File_System-as-IN-5.0.0-4.noarch.hdr

Global_File_System-as-IN- 100% |=========================|  12 kB    00:01
Error: failed to retrieve getPackage/Global_File_System-as-IN-5.0.0-4.noarch.rpm
from msuchy-5server
error was [Errno -1] Header is not complete.

yum-plugin request 
Range: 440-12984
but proxy answer 
HTTP OK 200 and not 206. But this should be OK. According w3c spec, "A server
MAY ignore the Range header" and if get from server 200 client should know it
get whole file, not just requested range. 
So in previus comment it have in file
Global_File_System-as-IN-5.0.0-4.noarch.hdr range 0-12544
yum-plugin should have somewhere this code
if return code == 206:
    do_as_do_now()
else if return code == 200:
    skip header_start bytes
    do_as_do_now()
    

The patch from bz #247327 c#9, resolves the issue for me.  Is this what is
expected?  Do we just want to make yum-rhn-plugin a little more robust so that
if requests with a Range header, but gets back 200, it still works?

Here's what I did:
1. Installed/Activated a rhn proxy 5.0 against production.
   rlx-2-04.rhndev.redhat.com
2. Registered my rhel 5 client through the proxy
   dhcp58-248.rdu.redhat.com
3. Set up a custom channel, slaglej-channel, and uploaded a package, to the
   custom channel.
   rhn-satellite-schema-5.0.0-27.noarch.rpm
4. Verified that the package will install manually using rpm on my rhel 5
   client, then rpm -e'd it.
5. Then, I:
   # yum install rhn-satellite-schema
   That prompts to download package, I hit y, then get:
   Error Downloading Packages:
  rhn-satellite-schema - 5.0.0-27.noarch: failed to retrieve
getPackage/rhn-satellite-schema-5.0.0-27.noarch.rpm from slaglej-channel
error was [Errno 14] HTTP Error 404: Not Found
6. If I apply the patch to my proxy from bz #247327 c#9, the package downloads
successfully.

Step 6 above should say:
... the package downloads *and* installs successfully.

Yeah, we should fix both end (proxy and yum-rhn-plugin). I fixed one end in
proxy5.0. But if users have proxy4.2, it will be broken for them (unless they
request hotfix or will wait for 4.3 [not known eta]).

Other advantage of this fix in yum-rhn-plugin can be (I think) that rhel5
clients can than work with - now not supported - older satellites, like 3.x

User jslagle's account has been closed

I am not certain how valid this feature change request to yum is:

Allow yum, that if it gets a complete rpm, instead of the partial rpm, header
only (as requested by a 206 Partial Content request) - to notice that it got a
complete rpm, and then gracefully parse it for the headers and use that rpm
already downloaded, then re-download the rpm. 

Cliff. 

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

 With the post RHEL-5.2 yum (3.2.7ish) we shouldn't be downloading headers, much
like Fedora doesn't. So that should solve this bug.

And what if connection is dropped during downloading? I think yum then try to
download only rest of file. I.e. use range header. Which will couse problem too.

It sounds like the move to 3.2.7 will change the header download behavior, will
it also address comment#17?

 Well comment#17 wasn't in the feature request in comment#14 ... and this
failure mode would be much less severe, no? (You could just yum clean all, and
try again).
 However AFAIK yum doesn't currently resume package downloads, in fact the only
thing that does range requests is the header downloading function.

I'm opening this bug again. I hope jlaska resolved it as NOTABUG by accident.
Becouse it is a bug.

msuchy: yes that was an accident, my apologies.  Thank you for catching! 

 Ok, I'm an idiot, but at least I can speak to seth ... yum doesn't do the
partial downloads because python-urlgrabber does it internally, so it looks like
the disconnected from proxy problem will still exist post 5.2 (although "yum
clean all" should fix it). 

 So the current RHEL-5.2 errata has the fix which makes it so headers aren't
downloaded anymore. This should solve most of the problem here.
 We can't fix the partial download is actually full download, easily, from
within yum ... and I think it will retry on everything apart from the (very
small) repomd.xml.

 So I'm going to add this BZ as fixed to the errata, unless you'd prefer me not
to, as I fixed everything I said I could fix.

OK for me.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0388.html