uc_file.pages.inc - cannot modify header information

Does this help? http://drupal.org/node/1424

Interestingly, uc_file.pages.inc has a blank line at the end, which is one of the stated causes in the book page.

I'm seeing the same error with my file downloads. For me, the log record for the header problem shows up after the record for the download.

Out of curiosity, are you implementing hook_file_transfer_alter() ?

OK, well at least that narrows it down - it's not something I'm doing in my code :-) I'm not using a download manager, so that rules out the "only occurs when a user is using a download manager" theory.

However, I think you're on to something with the drupal_goto(). Curiously, the drupal_goto() doesn't do anything. Try it - instead of redirecting to user/%/purchased-files change the source code to redirect somewhere else. Nothing ever happens, the user will stay on user/%/purchased-files. This is because the MENU_CALLBACK is handling the GET request from the browser, and is sending the file in response with headers that indicate it's a download not a page to be displayed in the browser. There has been no request for a *normal* page, so having drupal_goto() generate http 302 headers to send to ?? doesn't make any sense. By the time drupal_goto() is called, the file download has already been flushed.

So I think commenting out drupal_goto() in _uc_file_download_redirect() is the way to go. I've done that on my test server and will watch to see if that eliminates the error message.

But it sure would be nice to have the ability to redirect at the end of the download - that's what I was trying to get working all day yesterday!

I just discovered the PHP function headers_sent(), so I modified the uc_file code so that before calling drupal_goto() it first checks if it's too late to send the headers, and if it is too late then print out the headers (just for debugging) instead of calling drupal_goto():

--- uc_file.pages.inc.orig      Tue Jan  5 19:42:58 2010
+++ uc_file.pages.inc   Fri Jan  8 10:18:10 2010
@@ -356,6 +356,12 @@ function _uc_file_download_redirect($uid
   }
   // Redirect users back to their file page.
   else {
-    drupal_goto('user/'. $uid .'/purchased-files');
+    if (!headers_sent($filename, $linenumber)) {
+      drupal_goto('user/'. $uid .'/purchased-files');
+    }
+    else {
+      $headers = headers_list();
+      drupal_set_message('<pre>Headers sent from '. $filename .' on line number '. $linenumber .'</pre>');
+      drupal_set_message('<pre>Headers: '. print_r($headers, TRUE) .'</pre>');
+    }
   }
 }

The error in the original post disappears with this change because the headers have ALWAYS been sent at this point, so this check is equivalent to commenting out drupal_goto(). Basically, after the first print(fread($fp, UC_FILE_BYTE_SIZE)); in _uc_file_download_transfer() it's too late to send another header.

I think we can conclude the theory about drupal_goto() was right. It's too late to call it here, and it has no effect other than generating an error in the watchdog if it is called.

What should be the permanent fix? Is there any way at all to force a redirect after download? Maybe by adding another header early on? Or do we just comment out the drupal_goto() and forget about trying to redirect?

The attached patch, developed in discussion with torgosPizza, checks to see if the headers have already been sent before calling drupal_goto(). This eliminates the error for both of us.

Yeah, a quick Google search didn't show me anything that could easily make a redirect happen after the file had been sent. Even if we tried to send the redirect header before the file data, I'm sure something would get confused because we're trying to serve a page and a file in the same request.

Committed.

(I did test setting the Location header at the top of the file data, but as expected the browser just redirects, discarding everything that comes after the header. That behavior is not mandated by the HTTP spec, but in practice that's what happens with all browsers.)

for me when a user is trying to download a file same headers already sent message appears... but in line 315
uc_file.pages.inc:315
in my code Ubercart 2.2 line 315 is in flush();

              // Push the data to the client.
              print(fread($fp, UC_FILE_BYTE_SIZE));
line315 >  flush();
              ob_flush();

I didn't apply the patch... I'm going to try the patch now
it's a minor issue since the file downloads correctly and the user can't see the error .. only the admin. but it would be better if it's done correctly.

I removed the last blank line of the file
now the error appears in line 335

ok the message doesn't appear now that I applied the patch at #8
sorry for the trouble :)
Thanks

Still getting these errors for anonymous users downloading files

access denied 01.08.11 download/55/8dc918101a283d1fc3f4ee0d37a7d661 Anonymous
php 01.08.11 Cannot modify header information - headers ... Anonymous

We need to be able to redirect the user after the download of the file. Effectively the above suggestion of commenting out the drupal_goto to avoid the watchdog error ignores that the redirect does not occur, nor do drupal set message because the page is not refreshed. To see drupal set messages, the user has to manually do a page refresh or bring up another web page.

Has anyone been able to fix this problem so that a redirect can occur to a target webpage after the download is complete. The problem is that the headers are set for the download file to occur. Is there a way to close off those headers for the download and re-establish headers for a webpage?

I have not found a solution after much searching.....

This issue was about a specific bug which was fixed two years ago.

A new feature request should be opened if you want to help develop a redirect after download capability. (I think I eventually ended up doing that with jQuery.)