SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Remote host header already sent warning, but not on localhost...

    I'm experiencing a very strange problem with my php scriptie. I've been working on this little scriptie and all was fine until three weeks ago. Now it generates a header warning on the remote server, but strangely not on my test server.
    • I wrote up another little scriptie (see below) to test the header and make sure it was not the server. Same result: remote generates a warning and local does not.
    • I tested just the header in a php redirect file and this works correctly on remote host.

    I've posted elsewhere (I know, I should have brought it here first and went through the full broadsides of comments warning me to eliminate any, all, every, not a one, preceding space before the header function. This did not fix the problem, and if the script works without error on my localhost then, QED, its not in my file, per se...cuz bad code with spaces is bad code wherever you put it. haha

    This leaves me with few ideas of how to go forward. One thought is try to cause my localhost to repeat the problem. I was adding a magic_quotes scriptie when I got the flat tire, so I turned it on in my localhost setup to no effect.

    Code HTML4Strict:
    <!DOCTYPE html>
    <html>
    <head>
    <meta charset="utf-8">
    </head>
    <body>
    <?php
    	var_dump($submitted = isset($_POST['submitted']) ? 
    		$_POST['submitted'] : 
    		NULL);
    	if ($submitted) {
    		header ('Location: menu_edit.php?added=1');
    		print 'This is wrong!';
    	} else {
    			print 'Waiting...';
    	}
    ?>
    	<form method="post" action="<?php $_SERVER['PHP_SELF'] ?>">
    	<input type="submit" value="Submit" name="submitted" />
    </body>
    </html>

    Now, just moving the php to the top is not enough. I was working with a fellow in the other thread. We tried this next version. (NOTE: As I'm posting this I also rechecked the code to be sure I had the right version. Originally we believed he found a solution; however, as I recheck the file it is not working on the remote host and is working on localhost. Also, I decided to leave the other thread, cuz I don't agree with the the fellow's conclusion ignoring the fact my script, above, works on my localhost. Its not personal. I just need to resolve this problem

    Code PHP:
    <?php
    var_dump($submitted = isset($_POST['submitted']) ? $_POST['submitted'] : NULL);
    if ($submitted) {
    header('Location:menu_edit.php?added=1');
    } else {
    print 'Waiting for you.......';
    }
    ?>
    <!DOCTYPE html>
    <html>
    <head>
    <meta charset="utf-8">
    </head>
    <body>
    	<form method="post" action="<?php $_SERVER['PHP_SELF'] ?>">
    	<input type="submit" value="Submit" name="submitted" />
    	</form>
    </body>
    </html>

    And if that wasn't enough...I set this up on two remote hosting services. Both recreated the error. Maybe the answer is about these bare bones shared hosting setups? I loaded my server using YUM install. I also have not updated it since install in November. Maybe there was an update to some server plugin during these last four or five weeks?

    If I can't get an answer to this problem, I'm going to contact php.net and demand a refund!
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  2. #2
    ¬.¬ shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Does your local server have php setup to display errors?
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes. In browser and in an error_log file.
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  4. #4
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    That first piece of code should always generate a hearers already sent error if the header call is executed because the headers have to be sent before the < on the front of the doctype.

    So if it isn't giving that error then the condition to call the header() isn't being met.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  5. #5
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What I can tell you are my observations, carefully and faithfully presented as the facts of this problem. I would hope someone tries this code on their own server and verifies, or disputes my results.

    Chris

    PS. In the case someone tries this on their server, let me remind you to also change the location's URL to something that won't itself return an error.
    Last edited by xtiansimon; Jul 29, 2010 at 11:07. Reason: add ps
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  6. #6
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been investigating the possibility of BOM in the file as mentioned in my previous post and in other troubleshooting resources. And I found a sitepoint discussion about the BOM from last November. In this the discussion has two points I'd like to mention.

    First, there is the suggestion a file can be examined with VIM to look for the BOM characters:
    all *nix servers are guaranteed to have (n)vi(m) that the author could use via ssh.
    . And that's just what I did. On one server I examined my code with VIM via SSH and found nothing before my code. On the other server I used cPanel's text editor which has character encoding identification and a menu to select the correct encoding. Back to the same problem.

    Second, the is mention of the server making a declaration of the file's encoding,
    This is still an authoring error. If the server declares an encoding other than utf-8, then the author should either change the document encoding, or change the server header.
    I understand the author declares the encoding in the meta tag for the file. But can someone explain that last bit about the server header?

    Chris
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  7. #7
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I understand the author declares the encoding in the meta tag for the file. But can someone explain that last bit about the server header?
    The server sends a header before the file, imagine me saying "german: guten tag" vs "english: good day". Sending a meta tag as well is the equivalent of "german: (oops, I meant english) - good day". This can work (not sure on all browsers) because in theory everything before the <meta is universal (there should be no characters that can be misrepresented), so the browser should be capable of switching modes when it encounters that 'oops'.

    Basically, delete the meta tag, check what your server is sending, put the meta tag back to match that, and make sure your text editor is also saving in the same format. Or, change the server to match the text editor (and meta tag).

  8. #8
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by hash View Post
    Basically, delete the meta tag, check what your server is sending, put the meta tag back to match that, and make sure your text editor is also saving in the same format. Or, change the server to match the text editor (and meta tag).
    I like the way you're thinking.
    I removed the meta tag from the file, loaded the above pages, and viewed source. Nothing there to see before the opening <!DOCTYPE>. I even removed that leaving just <html>. There was no visible character before the first page tag.

    Mozilla shows the doctype as iso-8859-1. The other thing to do with this test is try to provide a positive result. Then what is the meta declaration for utf-8 with a BOM?
    Chris

    PS, Is it even possible to have PHP (and I guess some set up of the LAMP server) where Header() performs a redirect even though it is technically incorrect? If yes (as seems to be the case with my LAMP set up) then what would be the purpose?
    Last edited by xtiansimon; Jul 31, 2010 at 08:17. Reason: PS
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  9. #9
    SitePoint Wizard
    Join Date
    Nov 2005
    Posts
    1,191
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like the way you're thinking.
    lol you shouldn't. I skimmed this, my bad, looked like an unresolved qn so I answered the last post.

    The problem is that you are using var_dump() before a header call. var_dump typically outputs stuff, even if this is just 'null', so the problem becomes why is your local host not behaving correctly - the remotes are doing what I would expect, logic_earth had this nailed in post 2.

  10. #10
    Utopia, Inc. silver trophy
    ScallioXTX's Avatar
    Join Date
    Aug 2008
    Location
    The Netherlands
    Posts
    9,060
    Mentioned
    153 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by hash View Post
    so the problem becomes why is your local host not behaving correctly - the remotes are doing what I would expect, logic_earth had this nailed in post 2.
    I suspect the local host has output_buffering set to On or a numeric value in php.ini, while the remote hosts have this set to 0 (zero) or Off.
    Rémon - Hosting Advisor

    SitePoint forums will switch to Discourse soon! Make sure you're ready for it!

    Minimal Bookmarks Tree
    My Google Chrome extension: browsing bookmarks made easy

  11. #11
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The only place I found any reference to this error was at Wikipedia

    Be warned. I've been messing with this error since July 7th. My shared hosting service refused to acknowledge my site's code was working before this date and investigate any changes to their set up. I don't know why but they also have a forum in addition to traditional trouble tickets, and suggested I use their forum to ask for help instead A second shared hosting service I signed up for also had the same set up (no forum

    Hey, Sitepoint. What took you so long! haha!
    Xtian
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  12. #12
    SitePoint Member
    Join Date
    Aug 2010
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just had the same problem, thats why I ended up here.

    putting the following line in a .htaccess did the trick for me:
    php_flag output_buffering on

    Thanx to ScallioXTX

  13. #13
    SitePoint Zealot
    Join Date
    Oct 2009
    Posts
    114
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ThePixelChick View Post
    Just had the same problem,
    I doubt you had the same experience. X
    Dinopad R40 - F15/XP
    APACHE 2
    MYSQL 5
    PHP 5

  14. #14
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by ThePixelChick View Post
    putting the following line in a .htaccess did the trick for me:
    php_flag output_buffering on
    That's called hiding the problem - the problem is still there as you haven't fixed it, just hidden it away along with lots of other potential problems that you will now never know about and which might destroy your site.

    With properly written PHP that flag should never need to be on.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  15. #15
    SitePoint Member
    Join Date
    Aug 2010
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmmm... so I made it worse. Is there a better solution?

  16. #16
    SitePoint Wizard siteguru's Avatar
    Join Date
    Oct 2002
    Location
    Scotland
    Posts
    3,629
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Fix the source of the problem?

    Seriously - I've never found a situation where I've HAD to use output buffering to fix a problem; there's almost always a way to rewrite code to remove the necessity.
    Ian Anderson
    www.siteguru.co.uk


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •