up2date problems (use a mirror)

[Tyler larson]

On Tue, 2004-01-13 at 16:21, Dan Goodes wrote:
> On Tue, 13 Jan 2004, Tyler larson wrote:
> 
> > [*] - The fact that a server under load would transmit corrupted data is
> > disturbing in itself. The problem's not the network: TCP give you the
> > right data, or no data at all. It's either the client (that works fine
> > with other mirrors, BTW) or the server. I'm under the conviction that
> > the issue should be investigated at least.
> 
> I am not an expert (IANAE?) but I imagine that the problem may lie in the
> client - after a set idle timeout in up2date it seems to just drop the
> connection to the server and move onto the next package. The resulting RPM
> is obviously corrupt since it is incomplete. I am probably wrong there,
> but that's what it seems like to me - I can't imagine apache (or whatever
> download.fedora.redhat.com uses for HTTP) dropping a connection itself
> simply because of high load .
> 
> Just my 2c.
> 
> -Dan
> 

Sounds very plausible. I just looked over the up2date source (briefly,
mind you) and it looks like it's programmed to handle that situation
("except httplib.IncompleteRead": rpcServer.py,line 125), though I
didn't delve deep enough to see *how* the situation is handled.

Still depending on how things are done at the HTTP level, it's possible
for a terminated download to be falsely interpreted as a successful
download. (If no content-length is specified, the download is considered
complete when the server terminates the connection). This, of course,
*should never* be the case when using apache with static files, but it's
a possible cause.

Perhaps we might do something like check an MD5 sum for downloaded
files, and delete the bad RPM from /var/spool/up2date if it doesn't
match. As things stand, if you get a bad RPM in the download directory,
it stays there and is never re-downloaded, making updates fail every
time. The user has to delete the bad file manually, and obviously most
users don't know how, so up2date becomes "broken".