Dunno how important it is, but thought you'd like to know. I have XML sitemap installed on Drupal 7.28. XML sitemap custom, engines, node and taxonomy modules are enabled, internationalization, menu and user modules are disabled. I got this warning logged when someone with IP (seems to be an image bot belonging to the search engine Yandex) accessed my site's sitemap.xml:

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /sites/all/modules/xmlsitemap/xmlsitemap.pages.inc:118) in drupal_session_start() (line 287 in /includes/session.inc).

I tried to reproduce it by deleting cookies and going to sitemap.xml but had no luck. Maybe you'll eventually find a related issue or something and will be able to fix whatever caused this warning to appear.

Update: Got the same error with Google bot and Google bot simulator. So it's no random fluke but a full-blown reproducible bug. I'm increasing the priority from minor to normal. Please see what you can do about it.

#5 xml_sitemap-session_warning-2273855.patch335 bytesMatt V.
PASSED: [[SimpleTest]]: [MySQL] 525 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


Ari Linn’s picture

Title: Got a "Cannot send session cookie" warning with xmlsitemap » Got a "Cannot send session cookie" warning with xmlsitemap from search engine bots
Priority: Minor » Normal
Issue summary: View changes
Kristen Pol’s picture

I'm seeing these as well:

Drupal 7.28
XML Sitemap 7.x-2.0

Example IP addresses: - Vietnam - Vietnam - Singapore - India - India - Italy - India - India - India - India - Vietnam - Kenya - Vietnam - Vietnam - Vietnam - India

Based on the locations, maybe these are scrapers.

oadaeh’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

@Ari Linn: is that Google bot simulator still giving you those errors? I just tried it on a site, and it did not produce the error for me. Being able to reproduce the problem makes it more likely to be found and fixed.

Matt V.’s picture

Status: Postponed (maintainer needs more info) » Active

I work on a site that was logging the same warnings. It took a while, but I was able to track down at least one possible cause of the issue. It turns out that another module was adding session variables within hook_boot().

The session variables cause a problem because XML sitemap has already begun sending output within xmlsitemap_file_transfer(). When xmlsitemap_file_transfer() subsequently calls drupal_exit(), the session variables eventually cause a session to be started within drupal_session_commit(). But since the headers have already been sent, the warning is logged.

Matt V.’s picture

Status: Active » Needs review
335 bytes
PASSED: [[SimpleTest]]: [MySQL] 525 pass(es). View

Here's a quick patch to address the warnings, by unsetting the session variables. This may not be the best fix; I'm open to suggestions.

Matt V.’s picture

The more I've worked on the issue, the more I've realized how dependent it is on state (specifically sessions, cookies, and possibly also caching). To reliably recreate the issue, I do the following:

  1. regenerate the sitemap
  2. open an incognito browser window
  3. load the main sitemap.xml page
  4. visit any sub-page that hasn't yet been loaded since the regeneration

Using a fresh incognito window is important, since it will not yet have any cookies set. That allows you to more reliably mimic search engine crawlers, which don't typically accept cookies.

joelpittet’s picture

May have to do with the drupal_exit() which is calling drupal_session_commit().

How about a normal exit() call where you have that unset($_SESSION)?

print fread($fd, 1024*16);
+    // Exit as all that we need to send to browser has completed.
+    // drupal_exit() is causing the session to complain about output.
+    // @see #2273855.
+    exit();
   else {

Dave Reid’s picture

Status: Needs review » Postponed (maintainer needs more info)

Can this be replicated with a clean install of Drupal core + XML sitemap only? If not, then it sounds like other code is at fault for starting session variables on anonymous user sessions.

joelpittet’s picture

I am using session_cache and session_api modules, could be part of the problem, but I've not been able to reproduce but shows up in logs every once and a while.

Ari Linn’s picture

I'm probably going to raise this topic from the dead by posting, buuuut I finally got to debug my code. No, as far as I can see this bug can't be replicated with just a clean Drupal install and Xmlsitemap. However, it's very easy to mess the xmlsitemap_file_transfer() function with as simple a thing as a cookie. This is exactly my case. I have a module that sets a cookie in hook_init():

function mymodule_init()
	if (!isset($_COOKIE['cookiename']))
		setrawcookie('cookiename', getcookienamevalue(), REQUEST_TIME + 31536000, '/');

Create a module that sets a cookie in hook_init(), clean up your browser's cookies, try to access sitemap.xml and you'll be greeted with a nice and cute "Headers already sent" warning in your log. The mymodule_init() code works correctly on all generated pages generated by Drupal except sitemap.xml that calls xmlsitemap_file_transfer() that messes the output up. I'm not sure if Xmlsitemap should be the only one to blame for this, but IMO a module shouldn't complain about as trivial things as other module's cookies.

Update: tested both solutions offered here: unset($_SESSION) after closing the file in xmlsitemap_file_transfer() and using plain exit() instead of drupal_exit(). In my case, only the latter worked. The former generated 3 different warnings per request: Cannot modify header information, Cannot send session cookie, Failed to flush buffer, no buffer to flush.

joelpittet’s picture

Status: Postponed (maintainer needs more info) » Needs review

Couple responses to the postponed, setting back to Needs review

dpovshed’s picture

Folks, I believe this is a duplicate of #2546646: Warning: Cannot modify header information - headers already sent, and by the way, there is already a quite elegant solution attahced in the patch.

I propose to close this issue.