Added more caching for download streams #37
Conversation
| * @var array | ||
| */ | ||
| private $metadata; | ||
|
|
||
| /** | ||
| * @param RateLimiter $rateLimiter | ||
| * @param array $fileList | ||
| * @param string $buildDirectory |
There was a problem hiding this comment.
Please update the docblock before merge.
|
I assume that with these changes caching servers (like CloudFlare) will better cache the file downloads, but you risk losing download stats for cache hits. I think this is a good approach to see if it affects bandwidth at all, but if it does, we may want to explore doing a two step redirect for the file download. The first step (the URL exposed on browscap.org that is used by all auto-updating clients) would collect the stats (and do any of the rate limiting/ip banning that you do now) and then redirect to a second URL that would download the file. The first hit would send headers so that it isn't cached, the second would do the headers that you're doing in this PR, in hopes to trigger aggressive caching by Cloudflare (or any other cache servers between your server and the client). Unless of course you don't care much about the download stats (or have a different way to retrieve them from CloudFlare). |
|
Yep, I think this is a good first step. Download stats are a "nice to have" really, I've got to prioritise the bandwidth consumption reduction to avoid having disruption to people's scripts and things 👍 I'll tweak that docblock and merge this - thanks folks! |
#36 - enables caching as an experiment to see how it shapes traffic with CloudFlare caching.