This is what we do, although we don't use query strings as some network
appliances don't respect them with respect to caching.
We use a virtual directory instead:
//example.com/static/<git version>/images/blancmange.png
Where <git version> is obtained like this:
$ git log --oneline | wc -l | awk '{ print $1; }'
And nginx removes the virtual directory like this:
location ~ /static/([0-9]+)/ {
rewrite ^/static/([0-9]+)/(.+)$ /static/$2 last;
}
Static files are cached for a year:
location /static {
alias {{ web_static_dir }};
expires 1y;
add_header Cache-Control
"no-transform,public,max-age=31557600,s-maxage=31557600";
gzip on;
}
So a static file will be cached "forever" unless we do a release, at which
point the virtual directory changes to the new version and clients start
requesting (to them) a completely new static file.
Also note we don't copy to S3 as there's no way to do the virtual directory
without having a real directory for every release. CloudFront will read
files from a web site as well, and we don't need the extra deployment
complexity.
Regards,
-scott
On Wednesday, July 2, 2014 3:20:34 PM UTC-4, Cal Leeming [Simplicity Media
Ltd] wrote:
>
> You also have to consider client side caching, despite if you use the
> correct headers or not.
>
> One option is to use a cache buster using a value which changes on each
> release, but I'd advise against using random() cache buster as your caching
> efficiency will be impacted.
>
> //example.com/static/images.jpg?release=1000
> //example.com/static/images.jpg?release=1001
>
> Cal
>
>
> On Wed, Jul 2, 2014 at 7:08 PM, Chen Xu <xuch...@gmail.com <javascript:>>
> wrote:
>
>> Hi Everyone,
>>
>> I am currently using the following strategy to serve my static files,
>> basically I run collectstatic to copy all my files to my static files
>> directory, and then move it to s3, and cloudfront will pick it up from
>> there. However, I wonder if I set the cache period to be 1 day in my
>> cloudfront, and I upload new updated files to s3, are the files still going
>> to be the old ones until next time the cache expires?
>>
>>
>> Thanks
>>
>> --
>> ⚡ Chen Xu ⚡
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users...@googlegroups.com <javascript:>.
>> To post to this group, send email to django...@googlegroups.com
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CACac-qYBa0Pg0eYQfoVGNTk2jHXC2Y100-xkHAo0AA7%2Bk3cw_w%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/django-users/CACac-qYBa0Pg0eYQfoVGNTk2jHXC2Y100-xkHAo0AA7%2Bk3cw_w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/1adfeb0a-8735-4d21-9d8d-4c8a97e8e7c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
