5 ms·

I understand that view. But I am talking specifically about something that would just dump the code of the php file to the browser.

• yrashk 16y ago
  they just had a single typo i?php instead of <?php I guess somebody's using vim
  • jarin 16y ago
    That's why I always git diff and run tests before committing, I do that all the time :-/
    • drdaeman 16y ago
      And this is the reason one should separate production and development environments and NEVER edit any files on production servers (let `git push` or something similiar handle it)
  • russss 16y ago
    At Last.fm we had a Subversion pre-commit hook which ensured that all .php files began with <?. That would have easily caught this problem, no drama.
    • SoftwareMaven 16y ago
      Unless the file was checked in separately. If they were doing something like updating the db password, so they need to update "current running" and "up-and-coming" code. As a result, they may have made the change in production, with the typo, and the change in SVN, without the typo. I would put my money on something like this being the cause.
  • KevBurnsJr 16y ago
    +1 to russ. PHP syntax checking on precommit would have caught this. Edit: I'm wrong. It does not catch this.
    • zaidf 16y ago
      Not necessarily. Makes sense for syntax check to only check between php tags. Root of the issue is that by default php outputs anything not between php tags to the browser. Perhaps some sort of buffer control at the top most include can disable output to browser until a later time. That's pretty much how templating systems work except they don't disable output afaik thus leaving possibility of this open.
      • dexen 16y ago
        You could do ob_start(); include '...'; ob_end_clean();, but it turns out that die() (say, in a custom error handler) () causes an implicit buffer flush. So it's not a foolproof solution.
        • bluesnowmonkey 16y ago
          You can attach a callback to the buffer to prevent that implicit flush. ob_start(function() {});
          • dexen 16y ago
            Thanks, I'll investingate and probably adopt it for my code :D
        • KevBurnsJr 16y ago
          Or register_shutdown_function - http://blog.kevburnsjr.com/php-fatal-error-500 http://blog.kevburnsjr.com/php-fatal-error-500
      • bluesnowmonkey 16y ago
        Exactly right. There's no reason for a config file (or any of the setup code) to be writing output. A good way to force this is by immediately starting an output buffer with a callback that returns nothing, then calling ob_end_clean() after setup is complete.
    • dexen 16y ago
• Maxious 16y ago
  I think this was more of a systemic failure - the file that failed in this case was also relied upon to disable development mode/error output on production servers. I'm pretty sure my production web servers return a HTTP code 500 with no further output when they encounter an error with the php.ini-production configuration file provided in the PHP source distribution. The hitch was of course that the file in question had a "i?php" (someone was using vi and hit i too many times?) instead of "<?php" which lead the php interpreter to output that section of code as if it were HTML. That feature is something PHP could provide an option to disable and only allow explicit echo/print/printf which should be what templating engines use.
  • KevBurnsJr 16y ago
    Actually, PHP returns a 200 when it encounters a fatal error. This explains why it was indexed by Google.