I mentioned this previously in:

http://drupal.org/node/1334910#comment-5225856

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);
      break;
    // 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);
      break;
  }

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.

Files: 
CommentFileSizeAuthor
#1 esi-1375100-1.patch1.29 KBmikeytown2

Comments

Status:Active» Needs review
StatusFileSize
new1.29 KB

How does something like this look?

Tested and working, thanks.

Project:Fork of Edge Side Includes integration» Edge Side Includes integration
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.

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.