Posted by mikeytown2 on February 23, 2011 at 8:33am
6 followers
| Project: | Boost |
| Version: | 7.x-1.x-dev |
| Component: | Apache integration |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
When returning back to a page you have already visited & nothing has changed, Apache could return a 304 instead of a 200. This mean it would use the browser cache. I've tested this locally on my box and it appears to work with no issues. Feedback on this is would be appreciated. Etag is built from the files modification time and file size. If either one of these change then browser will request the full page.
Patch below
| Attachment | Size |
|---|---|
| boost-etag-only.patch | 1.49 KB |
Comments
#1
#2
Committed the bug fixes; here is just the experimental part
#3
Only needed to comment out one line
#4
Let browser keep for 5 seconds; no need to ask again for 304. - eventually make this configurable... something to do with min cache lifetime; set the max to 15 minutes as setting this too high can be very dangerous, but having this set is very powerful in terms of sites speed. Ctrl-F5 will bypass this.
unset Last-Modified header.
#5
and we are back to #3
#6
Reports have been good. Going to add this in soon.
#7
Marked #982212: Cache-Control no-store, no-cache in Headers. Why? as a duplicate of this issue.
#8
There's a discussion going on about ETags in Core now #1573064: Remove unique ETag hack as it is no longer necessary
I'd think this is the defined best practice - http://developer.yahoo.com/performance/rules.html#etags
#9
Interesting!
I think that in Boost we can rely on ETags generated by Apache, either from the filesystem inode, or the mtime (depending if in a cluster or not), since the cache is on the filesystem (unlike Drupal core).
If we rely on etags and do not impose "must-revalidate", we need to make sure that after a user login, the browser does not still serve pages from its cache, otherwise users have to reload each page after login.
Moving issue back to "needs review" since we should do more testing before committing this.