Bug 55502 - Allow package RPMs to be fetched via http cacheing proxy
Summary: Allow package RPMs to be fetched via http cacheing proxy
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
(Show other bugs)
Version: 4.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-01 13:48 UTC by Thais Smith
Modified: 2015-01-07 23:52 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-31 20:26:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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 

1. Check local disk for already-downloaded package (this already happens 
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.

Note You need to log in before you can comment on or make changes to this bug.