| 2012-04-16 14:46:57 |
Soren Hansen |
bug |
|
|
added bug |
| 2012-04-22 05:24:23 |
Launchpad Janitor |
branch linked |
|
lp:debian/apt-cacher-ng |
|
| 2012-04-30 09:54:22 |
Launchpad Janitor |
branch linked |
|
lp:debian/wheezy/apt-cacher-ng |
|
| 2012-05-25 21:50:12 |
Launchpad Janitor |
apt-cacher-ng (Ubuntu): status |
New |
Fix Released |
|
| 2013-04-08 23:21:05 |
Colin Watson |
nominated for series |
|
Ubuntu Precise |
|
| 2013-04-08 23:21:05 |
Colin Watson |
bug task added |
|
apt-cacher-ng (Ubuntu Precise) |
|
| 2013-04-08 23:23:13 |
Colin Watson |
description |
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.16~exp12ubuntu8/apt-pkg/acquire-item.cc:
// File was already in place. It needs to be re-downloaded/verified
// 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. |
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.16~exp12ubuntu8/apt-pkg/acquire-item.cc:
// File was already in place. It needs to be re-downloaded/verified
// 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. |
|
| 2013-04-09 00:04:32 |
Steve Langasek |
apt-cacher-ng (Ubuntu Precise): status |
New |
Fix Committed |
|
| 2013-04-09 00:04:34 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2013-04-09 00:04:38 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2013-04-09 00:04:41 |
Steve Langasek |
tags |
|
verification-needed |
|
| 2013-04-09 00:33:08 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/precise-proposed/apt-cacher-ng |
|
| 2013-04-15 12:39:44 |
Jonathan Davies |
tags |
verification-needed |
verification-done |
|
| 2013-04-16 08:59:52 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2013-04-16 09:00:27 |
Launchpad Janitor |
apt-cacher-ng (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
