caching problem with wget used by MacPorts infrastructure

[Joshua Root]

On 2011-5-19 07:18 , Marko Käning wrote:
>> Well I'm not certain of that, not having seen the headers they return
>> for your tarball URLs. It's also possible that the misbehaviour is on
>> the part of whatever's doing the caching (presumably a proxy?)
>>
>> - Josh
> 
> I responded to the ticket I posted 2 months ago concerning this issue. It had been on hold all this time:
> 
> https://bitbucket.org/site/master/issue/2616/download-files-are-not-up-to-date#comment-484970
> 
> Well, we'll see what they can say. :-)

The downloads appear to be hosted on Amazon S3, which I would imagine
uses a bunch of reverse proxies. They're not specifying any cache
control policy, which is fair enough given that they have no way of
knowing how often you're going to be updating the files. And of course,
making stealth updates is a bad idea to begin with.

So you might just have to accept that there will be a delay before the
whole CDN picks up the updated file (exact length depending on their
configured default expiry time). Different results when you downloaded
with a browser and then with wget could possibly just be a result of
hitting different front-end servers, one of which had the old file
cached and one of which didn't.

- Josh