Warning: Cannot modify header information - headers already sent (output started at includes/file.inc)

Hi, we have kind of the exact same bug here.

Did you find an explanation to this one ?

Also getting this same error. Looks like the session is getting destroyed & causing this issue. I'll work on a patch.

Warning:
Cannot modify header information - headers already sent by (output started at includes/file.inc:1989)

LINE: 466
FUNCTION: _drupal_session_delete_cookie()
FILE: includes/session.inc

STACKTRACE:

Have you tested the patch to see if it fixes the problem for you?

Marking this RTBC

What are the steps to reproduce this - i.e. when/why is this getting called after headers have already been sent? It looks like the patch might be hiding the actual bug (which is that the cookie is supposed to be deleted, but isn't).

Drupal 8 also looks like it has equivalent code in Drupal\Core\Session\SessionHandler so there's a good chance the bug needs to be addressed there too.

In our case, we have drupal serve images for other domains/servers. If a user gets logged out of drupal due to a session timeout and that request was the user generating an image then it can trigger this error.

Sending the file causes headers to be sent. I would suspect that advagg could cause a similar issue (as it generates static files as well) but due to css/js not being used on other domains/servers it doesn't cause this bug.

Thanks David_Rothstein for pointing out that SessionHandler::deleteCookie does have similar code :)

I've attached a patch for D8 based off of #4

The alternative to this would be to use drupal_save_session(FALSE); inside of file.inc. Not sure what the D8 equivalent would be.

D7 patch that uses drupal_save_session(FALSE); when transferring any file via php.

I am also having the same problem at my homepage of my site www.rumathi.com . the best way to solve it is to use drapul image cokiee 6.8

In D8 I think this would happen in BinaryFileResponse::sendContent() which is inside of Symfony so I'm tempted to put it in ImageStyleDownloadController::deliver() and anywhere else BinaryFileResponse is used.

SessionManager::disable() seems to be where this happens; I think I'm using it correctly.

Note that the way file transfers happen in D8 this might not be necessary; this might be a D7 and below issue.

Correct D8 patch

Patches pass tests on D7 & D8.

This appear to happen both at session_destroy and session_start.

For me it is session_start:

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at includes/file.inc:1973) in drupal_session_start() (line 287 of /var/www/virtual/www.ntvg.nl/includes/session.inc).

In both cases I'm wondering why a session does not already exist.

+++ b/core/modules/image/src/Controller/ImageStyleDownloadController.php
@@ -149,6 +149,12 @@ public function deliver(Request $request, $scheme, ImageStyleInterface $image_st
+      // Prevent writting to the session if PHP is going to transfer a file.
+      $container = \Drupal::getContainer();
+      $session_manager = $container->get('session_manager');
+      $session_manager->disable();
+

Let's inject session manager via create().

Same with ExportForm and FileDownloadController.

Is this the right method - Config::create()? Haven't done much D8 code yet.

@JvE Does #16 fix the issue for you?

@mikeytown2 - no, you need to add "session_manager" to create() function (there are already "lock" and "image.factory" there). This will send it to constructor of the class where you take it and save it into a class member. Then use it like this "$this->sessionManager->disable()" (assuming you saved it in a member variable called "$sessionManager").

Can I get a link to an example? The API site doesn't list where the code is called from in SessionManager::disable() so I don't have a good working example on how to do this. You could also update https://www.drupal.org/node/218104 with the correct way to do this in D8 that would be helpful as well :)

@mikeytown2: Yes, #16 gets rid of the warning.
But I have the feeling it is simply hiding the symptom of a different fault somewhere.
As in, why would a session not yet exist at that point in the code? Anonymous users? Then why does drupal want to start a session after sending a file?

@JvE drupal_set_message() will start a session so I don't think it's totally unreasonable for this to happen.

#16 works for me. I'm not seeing any warning as mentioned in this issue after applying patch #16.

I have faced similar issue in xmlsitemap module, which used modified file_transfer() function.
I have ported patch #16 and it works for me. Thank you.

https://www.drupal.org/node/2546646#comment-10190812

#16 fixes the error for my in D7 with the textimage module.

Just a heads up that even with #16 applied I got this error:

Cannot modify header information - headers already sent by (output started at /var/www/html/includes/common.inc:2658)

LINE: 1265
FUNCTION: drupal_send_headers()
FILE: /var/www/html/includes/bootstrap.inc

STACKTRACE:

I opened #2963530: "Cannot send session cookie" on image style generation. with steps to reproduce (on Drupal 7).

Problem, part I

The basic problem (in D7):
drupal_exit() is called in various page callbacks (*) after headers and content are printed.
file_transfer() is just one example.
The callers expect that drupal_exit() will NOT print additional headers.

However, if
- the session is in "lazy" mode (which happens on requests without a session cookie), AND
- some module writes to $_SESSION anyway (e.g. ip_geoloc).

Then drupal_exit() will send headers via
drupal_session_commit() -> drupal_session_start() -> session_start().

This would mean drupal_exit() is not fully suitable as a function for these page callbacks.

Problem, part II: Output buffering!

It is more complicated than that.
In most PHP installations, the initial output buffering level is 1 (the output_buffering setting is probably at 4096).
As long as output buffering is on level 1, the entire problem of "Headers already sent" does not exist!

One could write an example script /test.php like this, and it would be just fine:
https://3v4l.org/tn1fR

assert(1 === ob_get_level());
print 'before the header';
header('AAA:BBB');

However, the following script will produce the "Headers already sent" problem:
https://3v4l.org/1aM5E

assert(1 === ob_get_level());
ob_end_clean();
assert(0 === ob_get_level());
print 'before the header';
header('AAA:BBB');

Now file_transfer() is different from other page callbacks that call drupal_exit(), because file_transfer() also calls ob_end_clean() before anything else.
Interesting issue: #205227: If output_buffering = Off then ob_end_clean fails to delete buffer.

This means:

• If your PHP installation has output_buffering enabled, then the problem we see here only affects requests that call file_transfer(), and a few others.
• If your PHP installation has output_buffering disabled from the start, then the problem will occur on many other types of requests. I would even expect it to happen on regular page visits.

Solution

I considered a number of different options.

But in the end, I think the existing patch #18, or something similar, might be the best shot.

My first idea was to change drupal_exit() so that it never sends any headers.
Instead, always send the session cookie headers before the page callback (or never).
However, this does not work if we start with empty $_SESSION, and modules write to $_SESSION during page callback or during hook_exit().
Also, this would be completely unnecessary as long as output buffering is enabled.

The next idea was to keep output buffering enabled in file_transfer().
But this might cause memory problems (not sure).

So, something like #18.
But perhaps we should make sure that output_buffering is always on the same value, to make Drupal behave more reproducibly.

And perhaps provide a version of drupal_exit() that is guaranteed to never send any headers!

@JvE (#28):
(my answer below applies to Drupal 7)

But I have the feeling it is simply hiding the symptom of a different fault somewhere.
As in, why would a session not yet exist at that point in the code? Anonymous users? Then why does drupal want to start a session after
sending a file?

There is a "lazy" session mode in drupal_session_initialize().

  // We use !empty() in the following check to ensure that blank session IDs
  // are not valid.
  if (!empty($_COOKIE[session_name()]) || ($is_https && variable_get('https', FALSE) && !empty($_COOKIE[substr(session_name(), 1)]))) {
    [..]
  }
  else {
    // Set a session identifier for this request. This is necessary because
    // we lazily start sessions at the end of this request, and some
    // processes (like drupal_get_token()) needs to know the future
    // session ID in advance.
    $GLOBALS['lazy_session'] = TRUE;
    $user = drupal_anonymous_user();
    // Less random sessions (which are much faster to generate) are used for
    // anonymous users than are generated in drupal_session_regenerate() when
    // a user becomes authenticated.
    session_id(drupal_random_key());
    if ($is_https && variable_get('https', FALSE)) {
      $insecure_session_name = substr(session_name(), 1);
      $session_id = drupal_random_key();
      $_COOKIE[$insecure_session_name] = $session_id;
    }
  }

This means that session_start() won't be called in bootstrap.
Instead, in drupal_exit() or drupal_page_footer(), drupal_session_commit() is called, which checks if anything is in $_SESSION, and if so, calls session_start().

Is this still applicable for Drupal 9 and 10? If so, we need steps to reproduce, ideally with a failing test. We should update the issue summary to use the standard template also.

More information on this was asked for 8 months ago, specifically if this is still a problem, and none has been supplied.

Therefore, closing as outdated. If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.

Thanks!