Since IP geolocation notoriously creates a $_SESSION, it renders the entire site incompatible with Varnish.
This creates a problem for:

  • sites where IP Geolocation is only used for parts of the site, and the rest of the site should be cached
  • multisites where geolocation features are used only on one site, but kills Varnish on all

We're considering forking the module and make it use cookies for remembering lat/lon instead. Cookies can be ignored in Varnish, only letting it trough to non-cached pages.

With this post, I hope to get your opinions on possibilities and implications by doing this, and/or other suggestions for making the module compatible with Varnish.

Comments

rdeboer’s picture

rdeboer
Location Melbourne
commented

Are you sure about this?
Many Drupal modules store things in $_SESSION, including some core modules, I would have thought.... Would that render all of them useless for Varnish?

Have you considered using NginX instead of Apache? I believe NginX has reverse proxy cache capabilities built in that make use of Varnish superfluous... whether these break when data is kept in the $_SESSION, I don't know...

If you're happy to only use the geolocation features for authenticated users and not anonymous visitors, you now can. In which case it may solve your Varnish issue.... after some code changes in the IP Geolocation module.... Along the lines of what was done for this module: http://drupal.org/node/1117706#comment-4897540

rdeboer’s picture

rdeboer
Location Melbourne
commented

Another solution would be to use a database cache? Does CTools have something for this?

Nick Lewis’s picture

Nick Lewis commented

RE #1. It's a fact: Any page that uses $_SESSION will break varnish. This module breaks varnish for all pages at the very first line of hook_init.

farald’s picture

farald commented

Actually, we ended up forking the module, creating a custom lightweight version that stored the geolocation in a cookie rather than a $_SESSION.

This works by allowing the cookie to be considered only by pages that are explicitly excluded from varnish. It's a very simple proceedure.

  • Rewrite the JS to push the lat/lon to a cookie, rather than an ajax callback.
  • Rewrite hook_init to store the variable in a $global that lasts for only one callback, instead of $session.
  • Result is a cookie that can live forever, but be ignored by varnish wherever. When no cookie, no geo provided to the callback.

The same proceedure as the present one, but living only one pageview at the time.

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi farald,
Would you like to share your code?
A patch would be perfect, but maybe your code and the main module have diverged, so would be happy with just the plain source.
Rik

PS: would using CTools, i.e. ctools_object_cache_set(..) be a solution?

rdeboer’s picture

rdeboer
Location Melbourne
commented
Title: Varnish issues » Varnish issues... solved?
Assigned: Unassigned » rdeboer

I have created a tiny utility for issues like this : http://drupal.org/project/session_cache.
Taking advantage of the Session Cache API module, the latest dev version of "IP Geolocation Views and Maps" no longer has to use $_SESSION to hold session state. Instead that data may be held on either the database or in a cookie.
See the Session Cache API config page to select the preferred storage mechanism.

Please take the dev version of "IP Geolocation Views and Maps" for a spin and let us know how the module holds up for you in a Varnish context.

Rik

farald’s picture

farald commented
Status: Active » Fixed

Session cache module has a really interesting approach, and seems to solve things really smoothly.
Lots of approaches to choose from, so I'll call this fixd. :)

About the code mentioned in #4, It's project related and I don't have time to rewrite it for publishing. But if you care to have a look, send me a contact notice so I get your mail, and Ill send it to you. Only diff from your code is that it does most of the cookiework on the js side.

Status: Fixed » Closed (fixed)

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

adam_b’s picture

adam_b commented

Can I raise a late question about this issue...

We're using 7.x-1.9 without the user-location functionality, so the "Visitor marker color" is set to <none>. Will the caching still be an issue in this situation?

And does 7.x-1.22 have the facility to store the data in a cookie as mentioned in #6?

rdeboer’s picture

rdeboer
Location Melbourne
commented

Hi Adam,
Simply setting "Visitor marker color" to 'none' won't solve the $_SESSION issue. You'll have to disable the HTML5 location retrieval on the IPGV&M config page.

But if you use IPGV&M 7.x-1.22 together with Session Cache API and on the Session Cache API config page select Cookie rather than $_SESSION as you storage mechanism, then you're fine.

IPGV&M 7.x-1.22 offers other new features as well, especially if you use it in conjunction with Leaflet.

Rik

adam_b’s picture

adam_b commented

Thanks Rik. We do have the location retrieval disabled (I'm assuming you mean the "Employ the Google Maps API to reverse-geocode HTML5 visitor locations to street addresses" checkbox on /admin/config/system/ip_geoloc), but will update the module in any case.

rdeboer’s picture

rdeboer
Location Melbourne
commented

Yes please do as I do not support old versions.
Rik

kurtfoster’s picture

kurtfoster commented
Issue summary: View changes

RdeBoer, what are the chances of getting this fix into an alpha release or something. I run drush make to bring drupal core and all of my modules when I deploy my site, so I'm a bit nervous about using the latest dev version in case some new updates come in that I'm not prepared for which break my site.

rdeboer’s picture

rdeboer
Location Melbourne
commented

The current release 7.x-1.24 came out a long time after this issue and has support for the latest official release of Session Cache API in it.