I mentioned this previously in:


that inclusion of cache-control: private in the User ID and Role settings causes nginx to bypass caching the esi snippet.

At that time I worked around the problem by using Global and Page settings. However, on a site that has access control I can't use those settings, so I'm back to using User ID and User Role settings and back to having nginx refuse to cache the ESI snippets because of cache-control: private.

It is still my opinion based on http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 that nginx is correct in its behavior and that

    case 4:
    // User Role/Page.
    case 5:
      drupal_set_header("Cache-Control: private, max-age=$max_age");
      drupal_set_header("X-BLOCK-CACHE: " . BLOCK_CACHE_PER_ROLE);

    // User ID.
    case 6:
    // User ID/Page.
    case 7:
      drupal_set_header("Cache-Control: private, max-age=$max_age");
      drupal_set_header("X-BLOCK-CACHE: " . BLOCK_CACHE_PER_USER);

is not the proper use of cache-control: private because Varnish/nginx/akamai are shared caches and not single user caches like a browser client cache.

However, I see that the sample Varnish configurations rely on the private header in their VCL snippets, and I'm not sure how to rework the VCL.

#1 esi-1375100-1.patch1.29 KBmikeytown2


mikeytown2’s picture

Status: Active » Needs review
1.29 KB

How does something like this look?

brianmercer’s picture

Tested and working, thanks.

mikeytown2’s picture

Project: Fork of Edge Side Includes integration » ESI: Edge Side Includes
Version: » 6.x-2.x-dev
Status: Needs review » Reviewed & tested by the community

This has been committed here. Moving this issue to the 6.x-2.x branch of ESI.

mikeytown2’s picture

Status: Reviewed & tested by the community » Fixed

committed to 6.x-2.x

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.