Hi,
attachments and thumbnails are unique (because of there aid). So it's okay that these files can be cached by browser. But currently this is not possible because there is a lack of http header.
According RFC2616 caching is only possible when a 'Last Modified' header is sent to browser.
Maybe a solution:
Adding the following line (2x) to attachment.php:
header("Last-Modified: ".date(r,$attachment['dateuploaded']));
I tested it a time and can't see any errors or discrepancies.
Ähm, okay, somebody think this is not a bug and has moved my thread to 'Suggestions'...
Anyway: This header will _not_ force the browser (proxy etc.) to cache attachments. It only make is possible (if the browser wants to cache).
I bump this...
Also this could save a lot of traffic.
This looks neat - I already have some small modifications to attachment displays in my forum. Where would I need to add those two lines in attachments.php?
So say you have a zip file. You download it once. Then if you goto download it again it won't take as long?
Why put the work on the server to fetch a file when it can be done locally? Faster and less bandwidth. 2 points towards it, 0 against it.
I suppose the only issue that could occur with it would be if it was updated. But if that last modified header was there then it would solve that issue would it not?
Side note since this thread involves caching, I added the following to my .htaccess to handle cache expirations
#
# Cache controls
#
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/javascript A2592000
ExpiresByType text/css A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType application/javascript A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
</IfModule>
It forces cache reloads every 30 days. Great if your site does not edit themes very often. THis is important as there are at least 3 separate calls to CSS for each theme, often 4 or 5 calls. Add javacript to the mix and you can have dozens of HTTP requests for a single page load since the javascript are setup as individual files.
Of course with avatars and such that are getting a dateline code added in 1.6 its not a problem for browsers to pull the new files instead of using old cached versions. The javascript and CSS issue still exists, so a long cache time is needed and acceptable.
(2010-07-19, 06:13 PM)pavemen Wrote: [ -> ]Side note since this thread involves caching, I added the following to my .htaccess to handle cache expirations
[...]
Nice side note, but this has nothing to do with this thread.
(2010-07-19, 05:13 PM)Polarbear541 Wrote: [ -> ]I suppose the only issue that could occur with it would be if it was updated. But if that last modified header was there then it would solve that issue would it not?
Yes when the last modified date changes, the browser download the file again. Otherwise it tries to load the file from local cache first. So this modification will also work with MyBB 1.6 (and the possibility to update an attachment)
But be aware with the fact that adding the Last-Modified header will
not force the browser to cache a file. But it makes caching possible. Without this header caching is not allowed according RFC2616.
(2010-07-19, 06:39 PM)querschlaeger Wrote: [ -> ]Nice side note, but this has nothing to do with this thread.
i know, but if someone is searching for caching techniques, then that info may be helpful.
wasn't one the new features for 1.6 to add timestamps to the avatars and attachemnts? I don't recall if those requests made the cut or not. this would negate the need for the additional header information being sent, so it would be a performance improvment to not have the last modified sent?