[SOLVED] Header problem in reverse

[Edgewalker81]

I'm having an unusual problem - on my local W.A.M.P.  setup, my header() calls work perfectly well even if I managed to output some text to the browser.  This is confusing, and makes it very hard to debug that particular problem.  (It works even if I create a blatant test case and put it in the center of a page with print('...some HTML...'); statements above and below it works!)

 

I try never to do that, but it happened on one or two occasions, and I never noticed because on my test server, it happily redirects (tested with I.E. 7, 6, 5, and FF 1.5 and 2.0) even though it should simply fail.  It does (of course) fail in the normal ways if I upload to our web host.

 

Is there some PHP setting that might be allowing this?  I'd rather just suffer the error so that I know that I've made a mistake.  Obviously the best thing to do would be "make sure it never happens in the first place," but some of these projects are large and involve a lot of page interactions, and we all make silly mistakes once in a while, don't we? 

[akitchin]

it's likely the output_buffering setting in php.ini.  with this setting on (it defaults to off, obviously), PHP will capture any output to the browser, run headers at the end of output, followed by flushing the output (thus the term "output buffering").  check phpinfo() to see whether the setting is on and if so, turn it off to trigger the errors.

[Edgewalker81]

Thank you - I will at the next opportunity.  I have to wonder why all servers aren't just set up this way though - wouldn't it kind of be "principle of least surprise?"  Especially when the error that normally results is common enough to earn sticky posts in several well-knownforums.

 

Thanks for your help!

[akitchin]

if you installed your server from a package, it may simply have been defaulted to "on" by the installer so as to make it work "out-of-the-box" for the largest number of users.  it's counter-intuitive for a good, approximative development environment, so i imagine the package used was one that was tailored to the average joe who just wants to fuddle around, not a serious developer.

 

let's be honest - one isn't truly a developer until they've had the growing pains of installing AMP to work in harmony on their own.  plus, it's a great and not-at-all frustrating experience!

[Edgewalker81]

Actually, I installed it a year or so ago from the php site as a zipped package, and it was a small project to get it to work - so I'm probably the one guilty of changing the setting.  At the time I probably some reference in front of me to explain each setting, and without the experience to know that it would cause trouble down the road, I thought it made more sense to set it the way it is.

 

edit: I guess that is why "a little learning is a dangerous thing."

[akitchin]

you could look at the silver lining - if this had never happened, you wouldn't have known how to deal with it under potentially more urgent circumstances.  a little learning is only dangerous if one is unwilling to learn beyond that point.