Comment 3 for bug 1429285

ähm, did you realize that "Expires" is the exact time of your request (compare "Date") in your example? (See also the HTTP1.1 spec which will tell you that 'Expires' doesn't really mean what you think it does, so that the value it has is actually 'okay').

APT is using If-Modified-Since in its requests so (if a server supports it… not all do, but at least most) a server can respond with just a "304 Not Modified", so at least there isn't much traffic wasted even if you happen to request updates every few minutes (less effective for load itself of course, apt is trying to be nice here as well by e.g. being a proper keep-alive HTTP1.1 client, pipelining and not opening multiple connections to the same server). A hypothetical average website loaded by a average browser seems to be much worse from a load and traffic point of view…

Regarding the snippets:
The puppet one just runs update if the sources.list changed. That isn't your usecase as I haven't changed my sources.list for months…
The ansible one, well, its a hack. A hack which in the worst case opts you out of security updates for 12 hours. That can be a long time, so I really don't want to define an arbitrary value for "not necessary" which is (a lot) larger than zero. And I am not very keen on suggesting by providing an option for it that there is a good value for it which I just don't want to figure out myself.

The problem is basically that you don't know at which point an update makes sense. Your last update can be 10 seconds ago, but even if that is close, it could still be outdated data as the repository was updated in the meantime. What we would need is a 'soft' valid-until which specifies the time after which the next update is/was deployed. Just that this is pretty hard to predict (its easy to specify when the the update will start on the master [expect for times you want to do an emergency rollout], not so much the point it is finished and don't even try to speculate about when this will reach your mirror…).