I could use a little help understanding how this is supposed to integrate with Varnish. This module will allow information to be saved outside of a session cookie which is great because most configurations will skip caching if any session cookie is found.

However, I have noticed all of the caching solutions still use cookies in some way to either store the information or denote the Session Cache API session in use. Since these cookies would be cached for an anonymous user, wouldn't every user then be seen as the same session?

To use an example, IP Geolocation (https://drupal.org/project/ip_geoloc) saves the geolocation data into the session. Using the Session Cache API this information can be moved into its own cookie, a database cache which creates a cookie with a session ID or a file which creates a cookie with a session ID.

Depending on the Varnish configuration wouldn't these cookies either be cached, meaning they would show all anonymous users as having the same session, or stripped, meaning the backend would never see the session cookie?

Sorry if I am missing something here, but I am not seeing how having a unique cookie separate from a session enables caching with Varnish or another caching system.

Comments

rdeboer’s picture

rdeboer
Location Melbourne
commented

I'm not a Varnish expert, but what I understand is that the Varnish configuration allows for a different treatment of cookies compared to other session data.
Users have confirmed that the module works in a Varnish context.
I've asked people to supply their Varnish settings as an example to share, but no one has delivered yet.
Rik

steel-track’s picture

steel-track commented

I ran this by my co-workers and we seemed in agreement that as long as a unique identifier is being passed to the backend web server there is no way that Varnish can effectively cache a page using this module as a solution.

The three outcomes are:

1. The session cache cookie gets cached causing all anonymous users to appear as being the same user.
2. The session cache cookie is used as an additional hash for determining the uniqueness of a page, which means as many sessions as exist there will be copies of a page.
3. The session cache cookie will be ignored and never make it the backend web server.

If you or anyone else can show an example of how to reach a separate outcome I would love to see it, but to my knowledge the only way anonymous users can have unique identities is by containing all of the functionality in Javascript similar to how Google Analytics operates.

rdeboer’s picture

rdeboer
Location Melbourne
commented

A year or so ago I had a discussion with someone requesting a solution for using IP Geolocation Views & Maps in a Varnish environment.

He made the following points:

  • "Cookies can be ignored in Varnish, only letting it trough to non-cached pages, so can be used on sites where IP Geolocation is only used for parts of the site, with the rest of the site still cached."
  • "You can allow the cookie to be considered only by pages that are explicitly excluded from Varnish. The result is a cookie that can live forever, but be ignored by Varnish wherever."

That combined with the fact that IP Geolocation Views & Maps can be configured to execute the JS function getCurrentPosition() only on certain pages and only for selected roles, should give one plenty of flexibility to use IPGV&M in a Varnish environment.

Or so we thought...

steel-track’s picture

steel-track commented

I think you make a valid point I had not considered, that using varnish you could define pages on the site where the cookie is sent to the backend and the page not cached. This is something that could not be as easily achieved using a session cookie because you could accidentally log out a user.

Personally in my Varnish configurations I avoid path specific logic because it tends to lead to issues with ease of maintainability, but I think it is a good way to handle the cookies produced by this module.

Developers should ensure that Drupal's page caching backend is replaced in settings.php with Varnish or disabled because it won't understand the complicated logic that Varnish will be implementing.

Something like this should work in a vcl in sub vcl_recv:

if(req.url ~ "^/contact-us/map") {
  return(pass);
}
rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi steel-track,

Glad our thinking is now more aligned!

If you have a complete example of Varnish and Drupal configuration settings to work together with Session Cache API, please share!
I'll add it to the README and manual pages.

Rik

ben.kyriakou’s picture

ben.kyriakou commented

In my experience this module doesn't work with Varnish; I've spent a non-trivial amount of time looking at this and trying to figure out if any of the settings would allow the pages to run cached. Since all options use cookies to some extent, the answer is no.

Your point above means that you can use it on certain pages, but these pages will then not be using Varnish. I can see the utility of it if you need a solution purely for capturing values for anonymous users, but unless one of the options omits the use of cookies (such as IP-based caching) then to say this module is compatible with Varnish is misleading. IMO this should be removed from the module description.

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi Ben,

So sorry to hear you feel misled and feel you've wasted time using my module in a Varnish environment.

This module was not written predominantly for Varnish. It serves use-cases outside of Varnish.

The module description does NOT say "this module is compatible with Varnish" on all pages. The description makes one statement about Varnish: "The module comes in particularly handy when anonymous session data needs to be stored, which may not be viable using the standard $_SESSION way, due to constraints imposed by a caching engine or web accelerator like Varnish."

That statement does not mean that using this module with Varnish will solve all of your use-cases, on all or your pages. Naturally it cannot, for the reasons pointed out by yourself and others in this thread. But it works quite well for some and it is certainly a step up from using $_SESSION, don't you think?

If you have a more useful description to add to the project page for the use of this module in the context of Varnish, I'm happy to consider it.

Rik

rdeboer’s picture

rdeboer
Location Melbourne
commented
Assigned: Unassigned » rdeboer

Following the mentioning in #6 of using the IP address as the session id I have added it as an option on the module's configuration page. So now there is an option to not use cookies on any page, via the database or file-storage mechanisms, as an alternative to using cookies in combination with a page exclusion strategy.
I've updated the README.