Please provide a way to prevent If-Range header use
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt-cacher-ng (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Precise |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
SRU justification: See bug 1162876.
Original report follows:
I'm stuck behind a proxy that seems to filter the if-range header from requests from apt-cacher-ng.
This means that when apt-cacher-ng tries to refresh a volatile file by passing "If-Range: <last known modification time" and "Range: bytes=<last byte of the file>", all the remote server ever sees is the request for the last byte. apt-cacher-ng gets a HTTP 206 response back and concludes that the file hasn't changed.
This causes lots of grief because the Release file isn't updated, so the trust path from Release.gpg -> Release -> Packages.bz2 -> checksums of packages is busted.
I see this comment in apt-0.8.
// File was already in place. It needs to be re-downloaded/
// because Release might have changed, we do give it a differnt
// name than DestFile because otherwise the http method will
// send If-Range requests and there are too many broken servers
// out there that do not understand them
..suggesting that I'm far from alone with this problem.
description: | updated |
tags: |
added: verification-done removed: verification-needed |
Maybe not so far as you think, it's the first report of such kind (in almost five years).
IMHO not supporting If-Range correctly is an utterly stupid idea. It's like replacing red light bulbs with green ones in traffic lights and say: hey, it's good enough, it will be correct most of the time.
I will provide that option ASAP.