Is this something handled by Drupal? What PHP, Apache, Varnish settings affect cookies?

Additionally, what's the difference in cookie handling between plain-vanilla Drupal and Pressflow?

I was seeing that in drupal_session_commit() boostrap.inc calls session_destroy():

session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie. To use the session variables again, session_start() has to be called.

In order to kill the session altogether, like to log the user out, the session ID must also be unset. If a cookie is used to propagate the session ID (default behavior), then the session cookie must be deleted. setcookie() may be used for that.

Apparently in Pressflow drupal_session_commit() gets called on every page like this:

// Perform end-of-request tasks on every page.
drupal_page_footer(), common.inc
    // Write the session, and open one if needed.
    drupal_session_commit(), bootstrap.inc
        // If our user is anonymous, Pressflow "Destroys empty anonymous sessions"
        // Destroy all data registered to a session
            // Called by PHP session handling with the PHP session ID to end a user's session.
            sess_destroy_sid($sid), session.inc

What implications, if any, does this have for user tracking in software like Omniture and Google Analytics?

See related post to cookies here: https://stackoverflow.com/questions/871283/how-do-tracking-cookies-work

Link to Pressflow documentation.

  • As a side note, I searched Drupal 6's bootsrap.inc for drupal_session_commit() and didn't find it mentioned. Apparently is is something that Pressflow does differently. Would be interesting to know why (I imagine something with regards to performance) and how it affects cookies and statistics. Commented Mar 28, 2011 at 21:31
  • drupal_session_commit() is a Drupal 7 function; Drupal 6 doesn't define such function.
    – apaderno
    Commented Mar 28, 2011 at 22:23
  • Are you sure you are not using Pressflow 7? If you are using Pressflow 7, then the question should be tagged drupal-7.
    – apaderno
    Commented Mar 28, 2011 at 22:26
  • // $Id: CHANGELOG.txt,v 2010/03/04 00:15:28 goba Exp $ Drupal 6.16, 2010-03-03 Yeah, that's Pressflow/Drupal 6 version. Probably Drupal 7 got the idea from Pressflow ;) Commented Mar 28, 2011 at 22:41
  • The function body of drupal_session_commit() in Pressflow 6 and Drupal 7 is different as well. Commented Mar 28, 2011 at 22:46

4 Answers 4


Cookies/sessions are handled by both Drupal and PHP. Drupal register some functions that PHP will call, when certain things need to happen, like destroying a users session. PHP handles most of the basic stuff and Drupal override some of it, store users sessions in the database.

I'm not familiar with Omniture but if it's anything like GA, a users session/cookie wont effect tracking at all. Cookies are used to identify the user, so they don't have to type in their username/password at every page. Without cookies, Drupal wouldn't be able to tell the users apart and would need some other form of identification, like a login for every new page load.

This is why, some people try to steal cookies, as that is the same as having the user log in and leave the computer, given the thief full access.

  • According to this they might be using cookies to determine how ofter users return to the site: stackoverflow.com/questions/871283/how-do-tracking-cookies-work. Not something that I have either confirmed or denied yet. If they were using cookies indeed, how would the code posted in my question affect them? Commented Mar 29, 2011 at 12:43
  • If GA doesn't use cookies for tracking like the link I posted says, could you link to an official documentation that indicates so? Commented Mar 29, 2011 at 12:51
  • @ameteur I didn't say that GA didn't use cookies, but that the cookies that belong to the drupal site doesn't effect tracking. GA can create it's own cookies that can be used for anything they want, but they would be completely unrelated to the cookies used by drupal.
    – googletorp
    Commented Mar 29, 2011 at 13:07

1) Is this something handled by Drupal?

Drupal does handles cookies, but it only handles it's own first party cookie. Like @googletorp said, Omniture and Google Analytics use their own cookies.

2) What PHP settings affect cookies?

drupal_session_initialize(), on boostrap.inc calls session_set_save_handler(), which overrides PHP's default session handling funcitons with Drupal's.

On Pressflow, at the end of every page, drupal_page_footer() is called. The code shows that if the user is anonymous, Pressflow deletes the current session id from the database and empties any cookies that might have been set. Refer to sess_destroy_sid() on session.inc.

3) What Varnish settings affect cookies?

Both Google Analytics and Omniture are able to generate visitor statistics without cookies because statistics are generated using hard-coded image requests (web beacons). However, in order to track persistent statistics (how often x user comes to my page), Omniture issues a cookie with an unique user ID - and when that user comes back to my page, he presents me with that cookie and I can say "OK, user x visited me for second time this week, and third time this month, and so on". This is done using persistent cookies, which are an actual file sitting in the user's computer.

The problem with Varnish is that it is generally set to strip cookies from the request because if the request comes with a cookie attached to it, then Varnish doesn't serve a cached page. Because Omniture sets these cookies for every user out there, it means that if you don't strip the Omniture cookie from the request, Varnish is never going to serve a cached page.

So it's either you track persistent statistics, or you find a way to pass that cookie through Varnish, and yet manage to serve the cached page, which is something I haven't heard of yet.


The real answer is that both Google Analytics and Omniture use specific cookies (not the cookies used by Drupal), and perform their tracking completely independently of Drupal sessions.

The new session handler introduced by Drupal 7 (and later backported to Drupal 6) in Pressflow does not interfere with either Google Analytics or Omniture tracking of users.

For the same reasons, cookie-stripping in Varnish do not interfere with the tracking of users.

  • It depends at what metric you're looking at. If you strip Omniture or GA cookies in Varnish you will be neglecting the unique user ID Omniture or GA issued to that user in the cookie, and that user will count as a new visit to the site, since visits per user depend on cookies, while unique visitors are based on IP address. Commented Mar 29, 2011 at 23:28
  • Not at all. "Stripping the cookies" just means that those cookies will not reach your Drupal site. It doesn't matter at all, because your Drupal site doesn't do anything with them anyway. Google Analytics and Omniture create there own cookies, that are independent of Drupal's cookies. One doesn't matter at all for the other. Commented Mar 30, 2011 at 8:27
  • I'm not really worried about what Drupal does with analytics cookies, I know it doesn't do anything w/ them. However if those cookies are stripped, remember that they contain the recurring visitor information. You strip those cookies and both GA and Omniture won't know if you are a new visitor or not. So stripping cookies does matter. Commented Apr 13, 2011 at 21:16
  • "Stripping cookie" means that they do not reach the back-end of your site. They still exist on the client and are accessible by GA and Omniture javascript code. Stripping those cookies in Varnish has zero effect on the tracking done by GA and Omniture (as already stated multiple times :p). Commented Apr 14, 2011 at 21:12
  • Sorry for the back and forth, but I first needed to see with my own eyes that JavaScript could access cookies. I am still in the process of setting up a test that shows that JS can access them on the computer, even if they were stripped from the request. Commented Apr 20, 2011 at 14:25

All components handle user cookies on different levels.

Web browsers sets the cookies and make sure they're passed over to the next requests based on the domains criteria and expiration date (as par of a HTTP header).

Drupal reads cookies via PHP (setcookie/session_destroy) functions and authenticate the users.

Varnish parses incoming requests and decides whether page should be cached or not and it may have the logic to keep, modify or drop all other cookies that Drupal doesn't need to know about. Here is example Varnish logic (in .vcl file config) as result of configuring Drupal with Varnish:

  1. Append a semi-colon to the front of the cookie string.
  2. Remove all spaces that appear after semi-colons.
  3. Match the cookies we want to keep, adding the space we removed previously back. (\1) is first matching group in the regsuball.
  4. Remove all other cookies, identifying them by the fact that they have no space after the preceding semi-colon.
  5. Remove all spaces and semi-colons from the beginning and end of the cookie string.
  6. If there are no remaining cookies, remove the cookie header. If there aren't any cookie headers, Varnish's default behavior will be to cache the page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.