Description of Problem: Updating a number of machines is very slow, since the same (often large) packages must be downloaded repeatedly by each machine. It would be useful if it were possible to fetch the package RPM (not the header data) via normal http rather than over SSL. The RPM is already protected by both an MD5 and a GPG signature, so no security is lost. I envisage a procedure like: 1. Check local disk for already-downloaded package (this already happens anyway) 2. If option "Fetch packages through HTTP Cacheing Proxy" is not checked, goto 6 2. Fetch package using cacheing http proxy. 3. Check package. If package fails or is truncated, fetch package again with Pragma: no-cache set to force the cache to refresh. 4. Check package. If package still fails, the proxy is bad. Complain and fall back to SSL operation. Goto 6 5. Done fetching this package, proceed to next package 6. Fetch package using SSL method, proceed to next package In the general case the proxy's copy will be good, saving much download time and load on the RHN servers. Having to turn the option on in the first place forces the Sysadmin to assess whether or not his cache is going to work right.
We're kind of going that path. We still miss a configuration option and some tweaking to treat GET requests differently than regular XMLRPC calls (which go over POST), but the request is already cacheable, and was made cacheable exactly for this reason.
So then should this request be closed?
Yes, the client has a configuration option, useNoSSLForPackages, which allows one to do non-SSL GETs (independent of the protocol chosen for the server).
Fix confirmed with up2date-2.7.86-7.x.3.