Bug 55502

Summary: Allow package RPMs to be fetched via http cacheing proxy
Product: Red Hat Enterprise Linux 4 Reporter: Thais Smith <tsmith>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED CURRENTRELEASE QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: high    
Version: 4.0CC: cturner, gafton, mihai.ibanescu, pjones, srevivo, taw
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-01-31 20:26:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Thais Smith 2001-11-01 13:48:55 UTC
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.

Comment 1 Mihai Ibanescu 2001-11-01 16:07:02 UTC
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.

Comment 2 Greg DeKoenigsberg 2002-01-31 20:16:56 UTC
So then should this request be closed?

Comment 3 Mihai Ibanescu 2002-01-31 20:26:45 UTC
Yes, the client has a configuration option, useNoSSLForPackages, which allows
one to do non-SSL GETs (independent of the protocol chosen for the server).

Comment 4 Jay Turner 2002-05-15 12:38:59 UTC
Fix confirmed with up2date-2.7.86-7.x.3.