Disabled - Do not use ESI.
Not Cached - Use ESI, but never cache the content.
Global - Content is same on every page.
Page - Content changes based on the URL.
User Role - Content changes based on the user role.
User Role/Page - Content changes based on the user role as well as the URL.
User ID - Content changes based on the UID; otherwise it is the same as global.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | esi-1334910-10.patch | 7.1 KB | mikeytown2 |
| #9 | esi-1334910-9.patch | 8.48 KB | mikeytown2 |
| #4 | esi-1334910-4.patch | 3.55 KB | mikeytown2 |
| #3 | esi-1334910-3.patch | 29.53 KB | mikeytown2 |
Comments
Comment #1
brianmercer commentedAre these things that can already be done with Panels variants?
Comment #2
mikeytown2 commentedI'm following blocks on this; I have blocks working currently and I'm working on getting this flying with panels. Having fine grained control over how the cached content behaves in varnish/nginx/browser is important.
Comment #3
mikeytown2 commentedThis code has been committed
Comment #4
mikeytown2 commentedThis has been committed as well
Comment #5
brianmercer commentedI'm not sure this is the intended use of the "Cache-Control: private" header.
I interpret http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html to say that a shared cache like Varnish or nginx should not cache a private response, but that a single user cache, like a browser cache, may cache it.
Right now your User Role and User ID settings are sending "Cache-Control: private, max-age=$max_age" which might as well be "Cache-Control: no-cache" to nginx because nginx interprets private as no-cache.
I see you're using it in your VCL, but nearly all the VCLs I can find on the web interpret private as no-cache. https://www.varnish-cache.org/trac/ticket/477
Comment #6
mikeytown2 commentedSounds like this needs some more thought... any ideas on how to accomplish the per user and per role cache? I haven't looked into the details of how this works currently in ESI so there could be a nice solution to the problem; just seeing what options are available.
Controlling what esi_add_cache_headers() does sounds like it might need to be abstracted depending on the solution we come up with, as what is in there now works great for AJAX.
Comment #7
brianmercer commentedThe nginx cache key is configurable but usually includes the request uri like a typical Varnish cache key so these would work:
/esi/panels_pane/mytheme:7:37/SESSlkas98f987sdf987sd987f8d97sfsd87f987
/esi/panels_pane/mytheme:7:37/RSESSlkas98f987sdf987sd987f8d97sfsd87f987
/esi/panels_pane/mytheme:7:37/PATH=node/2343
The sample VCLs that come with ESI add the session to the cache key from the cookie, which could be done in nginx also, though uri would be easier. Some Varnish docs suggest the cookie method also: https://www.varnish-cache.org/trac/wiki/VCLExampleCachingLoggedInUsers They may assume that it's easier to do this way with some VCL than to add it into the uri from the application code.
The ESI sample VCL does the same thing for roles with a cookie beginning with RSESS with a hash of a set of roles. For some reason I'm not getting that cookie. Also "Pass the current url to the external url as a base64 encoded string" doesn't seem to do anything. I've only tried them with Panels.
Comment #8
mikeytown2 commented"Pass the current url to the external url as a base64 encoded string"
This only works if you set an external URL in the textfield. Our setup is a blend of Drupal & .Net; being able to pull in external resources (not in Drupal) like this is important for us. If there is a standard for passing context that would be nice to follow; otherwise I'll be creating my own.
If you set the scope to "page" the base64 version of the URL should be added to the ESI request; which will then get decoded and turned into $_GET['q']
Comment #9
mikeytown2 commentedI'm a little hesitant about adding the Cache ID to the URL; so I'm thinking it will be an option that one can configure.
In the mean time I've modified the AJAX code to correctly replace CACHE=* with the ID from the cookie. This means that logging in/out with AJAX enabled will no longer cause issues as the browser cache could have had the wrong version of that bit of content. The patch attached does this and has been committed.
Comment #10
mikeytown2 commentedThis patch has been committed. Allows for CACHE=* to be fully set or as a dynamic replacement (default).
Comment #11
brianmercer commentedLooks good. I'm having a problem with my nginx config looping when using cached esi snippets. I have to work that out before I can test the new settings.