Cannot modify header information...

jlee - May 18, 2007 - 05:06
Project:Path Access
Version:5.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:needs work
Description

This may or may not be caused by this module.... however I only noticed the error after installing and activating the module...so I am passing this this along.

During navigation...users are "sporadically" presented with this error message:

warning: Cannot modify header information - headers already sent by (output started at /home/mysite/public_html/includes/bootstrap.inc:546) in /home/mysite/public_html/includes/common.inc on line 141.

Is this a bug in the module code?

Thanks

#1

bennyfio - July 12, 2007 - 19:42

I am getting the same error... if Path Access is enabled and Caching mode is set to normal almost 50% of times there is that warning message being shown, disabling the plugin the issue disappears.

#2

budda - August 27, 2007 - 14:28
Status:active» postponed (maintainer needs more info)

This is really hard to diagnose. I've not had this problem myself on about 10 sites which the module has been deployed on.

The module function path_access_init() gets called on every page load, but does no printing to the screen to cause such an error that you have reported.

Are you able to re-create this problem from a clean Drupal 5.x install? What web server are you running on? Do you have the aggressive caching option in Drupal enabled?

#3

bpsommerville - September 17, 2007 - 07:34

Another data point.

We have had this problem for a while. I tried upgrading to the dev version of path_access and still saw the same problem.
Disable path_access & it goes away, reenable and it comes back

#4

gjxl - September 17, 2007 - 20:31

I can confirm this problem. It seems the problem only manifests itself when you ask for a page with a browser that doesn't support gzip (I only get it from some bots that query my site, or if I use wget).
I can easily reproduce the error when:
- Caching is set to normal
- I request a cached page with wget

#5

budda - September 17, 2007 - 20:59
Version:5.x-1.1» 5.x-1.x-dev

So if you turn off caching completely the problem goes away?

Does anybody know a solution for this as i don't currently have spare time to test and create a solution.

#6

gjxl - September 17, 2007 - 21:22

No caching -> no bug
Aggressive caching -> no bug

I would guess the problem is with the call to 'drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH)'. Since that recursively calls the bootstrap stuff (since path_access_init gets called from the LATE_PAGE_CACHE bootstrap fase).

I don't really understand why you need that call either. I guess it's just for access to the 'drupal_get_path_alias' function in the cache bootstrap phase. But page caching is only for anonymous users, and therefore restricted pages will never be in the page cache.

So I guess you could just drop the call the drupal_bootstrap, and instead explicitely check if a cached page is being served, and in that case just return from your path_access_init without doing anything.

#7

gjxl - September 17, 2007 - 22:05

Ok, I've digged some more into this, and my previous comment is right. It's actually an incompatibility between Statistics module and Path_access module (the error doesn't occur with statistics module disabled). It's because they both call drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH), the second call (in statistics_exit) will result in a DRUPAL_BOOTSTRAP_FULL.
The way drupal_bootstrap is setup doesn't really cater for repeated (let alone recursive) calls to it.

#8

budda - September 17, 2007 - 22:16
Status:postponed (maintainer needs more info)» needs work

Thanks for your investigation in to this. makes sense that i never noticed it as i've not used statistics.module on any live site before.

If you could provide a replacement _init() function i would be happyto stick it in -dev for others to test before committing to a new point release.

#9

gjxl - September 17, 2007 - 22:36

Hum, I don't see any obvious way to determine the bootstrap phase, so my previous suggested solution might be unfeasible.

Alternatively you could just replace:

     drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH)

by:

     _drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH)

(Thus calling the internal functin with leading underscore).
This requires some testing though.

#10

budda - February 9, 2008 - 18:38

Did anybody try this on their local install to see if it resolved the issue?

#11

DanielTheViking - February 10, 2008 - 12:22

Subscribing.

#12

Doobyfrucan - February 21, 2008 - 12:07

I'm having the same problem with the second call to drupal_bootstrap (although in a custom module based on statistics)

#13

halftone - March 16, 2008 - 17:56

Same problem here.

#14

ratskates - March 20, 2008 - 12:00

is there a patch for this problem yet ? path access is a very useful modu

#15

gjxl - July 23, 2008 - 23:09

I've been running my drupal with the change as suggested in #9 since that time succesfully now. Don't see any side effects.

 
 

Drupal is a registered trademark of Dries Buytaert.