Comment 4 for bug 1429285

$ echo "now: $(TZ=GMT date)"; wget -S -q http://azure.archive.ubuntu.com/ubuntu/dists/vivid/Release -O /dev/null
now: Fri Apr 3 14:37:31 GMT 2015
  HTTP/1.1 200 OK
  Date: Fri, 03 Apr 2015 14:37:31 GMT
  Server: Apache/2.2.22 (Ubuntu)
  Last-Modified: Fri, 03 Apr 2015 14:28:00 GMT
  ETag: "34f32-512d2c15bbc00"
  Accept-Ranges: bytes
  Content-Length: 216882
  Cache-Control: max-age=1228, proxy-revalidate
  Expires: Fri, 03 Apr 2015 14:58:00 GMT
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive

So the 'Expires' is most definitely in the future. This one is currently 21 minutes in the future.

I didn't say that the solutions I pointed to were complete, but the fact that people are attempting to solve the problem (and doing so incorrectly) should indicate a need for a good solution.

It would seem possible for apt to go through the sources.list (+sources.list.d/*) and figure out what it was going to download. It could decide based on previously stored headers or a global default "5 minutes" or a per-mirror default if it should bother. Of course it would make sense to have the ability to force.

running 'apt-get update' on a system does take real time. On a cloud instance with a on-network mirror:
% TIMEFORMAT='real=%3lR user=%3lU sys=%3lS' bash -c 'for i in $(seq 1 10); do printf "%-3s " $i ; time apt-get update -q >/dev/null; done'
1 real=0m3.987s user=0m3.628s sys=0m0.244s
2 real=0m4.052s user=0m3.688s sys=0m0.220s
3 real=0m3.980s user=0m3.656s sys=0m0.204s
4 real=0m4.077s user=0m3.676s sys=0m0.272s
5 real=0m4.068s user=0m3.732s sys=0m0.228s
6 real=0m4.052s user=0m3.688s sys=0m0.236s
7 real=0m4.201s user=0m3.812s sys=0m0.248s
8 real=0m4.247s user=0m3.852s sys=0m0.252s
9 real=0m4.059s user=0m3.688s sys=0m0.256s
10 real=0m4.064s user=0m3.680s sys=0m0.252s

It just seems reasonable to me, that operations 2->10 could take .002 seconds.