Comment 6 for bug 214612

So this may be more important than its "bug importance" would imply.

It would seem that the Ubuntu archive sets Expires: headers about 25 minutes after the modified time of the file it is serving:

[ ] Release 17-Apr-2012 06:53 48K

$ HEAD http://archive.ubuntu.com/ubuntu/dists/precise/Release
200 OK
Cache-Control: max-age=1762, s-maxage=3300, proxy-revalidate
Connection: close
Date: Tue, 17 Apr 2012 07:18:51 GMT
Accept-Ranges: bytes
ETag: "c19b-4bdda64880a80"
Server: Apache/2.2.14 (Ubuntu)
Content-Length: 49563
Content-Type: text/plain
Expires: Tue, 17 Apr 2012 07:48:14 GMT
Last-Modified: Tue, 17 Apr 2012 06:53:14 GMT
Client-Date: Tue, 17 Apr 2012 07:18:51 GMT
Client-Peer: 91.189.92.170:80
Client-Response-Num: 1

Any skew between the Release, Release.gpg, and especially Packages.gz file, means that apt reports a 'hash sum mismatch'. This is particularly frustrating while testing deployment/automation during the dev release, because the files keep on changing.

With the influx of more apt sources (backports, multiarch, extras), the potential for running into this skew gets larger and larger. The Expires: headers means that if you happen to cache the responses mid-update (pretty easy with 5 - 8 minutes seeming the average between Packages.gz and Release writing), then you will have a broken cache for 25 minutes.

With the pdiff format, it would seem that the window for archive skew is, if nothing else, smaller and less painful to repeat. Its also conceivable that Expires: can be relaxed a bit, perhaps to just 10 minutes, if the pdiff format is used since in theory people requesting Release and the pdiff index twice will not be as bad as re-requesting Packages.gz.