This bug has been fixed in this release
From 175153: Right now, rhnlib shouldn't behave any differently than it currently does. The only difference is if, at some point in the future, the backend issues a 302 redirect, the newer rhnlib will follow it. Unfortunately, there is not currently a clear path to having RHN Hosted issuing 302 requests until certain contract/etc issues are worked out w/ the 3rd-party provider. A decision has been made to leave the code in for 3u8/4u4. This was deemed especially important as it's not certain there will be a 3u9. Normal up2date usage should sufficiently regression-test the new rhnlib codebase, and once we understand what 3rd-party provider we'll be going with, we will either be able to: a) use the existing implementation, test it, and hopefully just turn on everyone that consumed the 3u8/4u4 rhnlib and make them all happy, or b) have to change the implementation due to 3rd-party provider requirements. If this happens, we'd have to errata rhnlib anyway, so we simply bump the version of the client capability and only issue redirects to the known good ones. I hope this explanation is sufficient for qa's purposes, please let me know if not.
part of the larger up2date test effort for rhel4 u4
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/RHEA-2006-0490.html