I found this, which is the issue I am trying to solve, but it's for D6/Views 2: http://drupal.org/node/392106
Tried to implement the same thing in D7/Views 3. I used Nid as a contextual filter and set the validator to "Content", Filter value format to "Node ID", and Action to take as "Show 'Page not found'" but now my logs are spitting these errors when any of the invalid urls are accessed:
Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/includes/common.inc:2575) in drupal_send_headers() (line 1225 of /var/www/html/includes/bootstrap.inc).
I have not hacked core, and I've looked at all my theme's php files to make sure there is no extra whitespace at the end, which I read elsewhere causes similar messages.
Any ideas on what could be causing this or how I can go about debugging it?
Comment | File | Size | Author |
---|---|---|---|
#16 | views-1414068-16.patch | 1.13 KB | valderama |
#15 | garbled_404_output_via_varnish.png | 572.05 KB | valderama |
#11 | views-headers-sent-warning-1414068-11.patch | 556 bytes | nickkwest |
#8 | views-1414068-8.patch | 1.07 KB | tim.plunkett |
#7 | 1414068-7.patch | 301 bytes | swentel |
Comments
Comment #1
no2e CreditAttribution: no2e commentedI have the same problem (trying to find a solution for the same reason like you: #1432230: Prevent duplicate content (because Views returns 200 instead of 400) )
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedIn current 7.x-dev, common.inc line 2575 is this:
Does that mean your site is in maintenance mode when this happens?
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedSince you may not actually be running the very latset Drupal 7 you may want to look at the line that it says sent the output to see exactly what was output.
Comment #4
no2e CreditAttribution: no2e commentedIn my case (Drupal 7.12; Views 7.x-3.1; site not in maintenance mode) the warning is:
Line 2607 of includes/common.inc is in the following function:
(line 2607 is
ob_flush();
)Comment #5
narenpg CreditAttribution: narenpg commentedI am getting the same issue. when i tried to download private files.
Recent Log messages:
Type php
Date Thursday, March 29, 2012 - 09:46
User admin
Location https://example.com/drupal7/system/files/admin_menu-7.x-3.0-rc1.tar_.gz
Referrer https://example.com/drupal/content/test-private-files
Message Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/drupal/includes/common.inc:2607) in drupal_send_headers() (line 1243 of /var/www/html/drupal/includes/bootstrap.inc).
Severity warning
Comment #6
lathanThe handling of the 404 is done here.
in views_plugin_display_page.inc
in views.module
and inside class views_plugin_display_feed extends views_plugin_display_page which i dont think is relavent here they are all handled the same way " return drupal_not_found();"
Comment #7
swentel CreditAttribution: swentel commentedMight be the fact that drupal_not_found() is used, although I'm not even sure about that. The api doc says that the MENU_NOT_FOUND constant should be returned in a page callback that wants to return a 404, so the attached patch might probably fix the headers not sent message. Note, haven't tested this at all, but it might help.
Comment #8
tim.plunkettThis is the correct fix.
While I was clarifying the @return docblock, I noticed it still uses array_shift and phantom parameters, which aren't as obvious as fully documented ones.
See #1216758: Add $module and $hook as formal parameters in module_invoke() for the switch made to module_invoke/module_invoke_all.
Comment #9
dawehnerAwesome, looks perfect. Committed to 7.x-3.x
Comment #10
marcoka CreditAttribution: marcoka commentedstill getting header errors when calling a url that is wrong and will return "Page not found". Its a view that tages the tid as an argument.
Sample url: http://dev.text2.com/en/taxonomy/term/4762222222222222222/0?page=62
Header errors:
Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/includes/common.inc:2575) in drupal_send_headers() (line 1225 of /var/www/html/includes/bootstrap.inc).
Comment #11
nickkwest CreditAttribution: nickkwest commentedRan into this problem running Views 7.x.3.5 and it's present in 7.x.3.x
views/plugins/views_plugin_display_page.inc execute() is returning drupal_not_found() and should be returning MENU_NOT_FOUND instead.
Comment #12
RobertOak CreditAttribution: RobertOak commented#11 stopped numerous PHP errors of headers already sent, session_start() [function.session-start]: Cannot send session cache limiter - headers already sent,
Notice: ob_flush() [ref.outcontrol]: failed to flush buffer. No buffer to flush. in drupal_page_footer()
in Views 7.x.3-5.
Comment #13
sredhead CreditAttribution: sredhead commented#11 also prevented the "Warning: Cannot modify header information" for us. We're using 7.x-3.5.
These messages appear if you have a contextual filter with 'Show "Page not found"' set as the 'Action to take if filter value does not validate'.
I notice that that "return drupal_not_found();" also appears in plugins/views_plugin_display_feed.inc, which probably also needs changing.
Finally, there's a "return drupal_access_denied();" in plugins/views_plugin_display_page.inc which should probably be "return MENU_ACCESS_DENIED;"
Comment #14
philsward CreditAttribution: philsward commentedGlad I found this post... these errors have been driving me nutts...! I totally agree with comment #13:
Looking at the common denominator of my errors, each one is from a view with "said" contextual filter.
I should also note that I have my 404 error page overridden with my own custom node, in-case that helps narrow it down a bit...
Comment #15
valderama CreditAttribution: valderama commentedThis bug also disturbes the varnish cache, at least on the Acquia Dev Cloud.
On views pages, with invalid arguments, and the "Show 404 Page not found" action, the output via varnish is garbled (see attached screenshot). For authenticated users the output of the 404 page is fine.
After changing the file as suggested in the patch from #11 the problem disappeared.
Comment #16
valderama CreditAttribution: valderama commentedAs the patch in comment #8 was comitted already, but does not fix the problem in all places, here is a new patch which basically adds the fix to more places.
Please review.
Comment #17
dawehnerThis look pretty nice and RTBC. Some manual testing by another person would though be really cool!
Comment #18
Demonthorn CreditAttribution: Demonthorn commentedThanks you, i applied your patch and all problem was resolved.
Comment #19
pfx CreditAttribution: pfx commentedthe patch works for my site too.
thank you!
Comment #20
mjpa CreditAttribution: mjpa commentedPatch in #16 works for me with Views 7.x-3.7 and latest release of Drupal.
Comment #21
Phizes CreditAttribution: Phizes commentedClarifying title.
Another +1 on RTBC on patch in #16.
Fixes the following errors for me, on 4 sites so far:
Please let me know if I have incorrectly used tags.
Comment #22
Summit CreditAttribution: Summit commentedWill this be committed please? Greetings, Martijn
Comment #23
rjacobs CreditAttribution: rjacobs commentedAnother +1 on RTBC on patch in #16. This took some time to trace back to views, but once I did this issue was a direct match to the problem we were experiencing. The patch sorted things out for 2 sites and a quick code review indicates that it's very consistent with the accepted logic of the patch in #8.
Comment #24
helmo CreditAttribution: helmo commented+1 for committing this clear fix. It also lead me to fix a similar issue in some custom code.
Comment #25
aspafford CreditAttribution: aspafford commented#16 fixes the php warnings for us as well, using views 7.x-3.7 and drupal 7.23.
Comment #26
Les Lim#16 is definitely the correct fix. I'll see if I can ping dawehner on IRC.
Comment #27
dawehnerPushed and committed to 7.x-3.x
Comment #28
maximpodorov CreditAttribution: maximpodorov commentedThe same thing is just fixed in Drupal core 7.25.
Comment #30
aubjr_drupal CreditAttribution: aubjr_drupal commentedI'd like to add that it also affects Panels (Page Manager) in the following edge case: If you create a page and give it the URL /your/page, and then limit it with a Selection Rule (String: URL path) so that you get a 404 error when you go to /your/page/URLToNothing, (instead of it redirecting to /your/page, which is the default behavior), this problem appears.
When the String: URL Path selection rule is removed, the problem goes away (since it's no longer a 404).
What made the error go away in my case was testing an identical change to Page Manager in modules dir/ctools/page_manager/plugins/tasks/page.inc on line 324 (v. 7.x-1.3). I didn't leave the change in, but it appears that this is a substantial problem in certain cases.
Comment #34
Dave ReidComment #35
xjm