3

To preface: this has got to be one of the strangest bugs I have ever seen, especially since it comes and goes.

There exists a page called view.php and another page called save.php. The bug manifests when I request save.php - I instead get view.php. Request headers say save.php, and it happens in Firefox, IE, Chrome, Opera, Safari. It happens consistently unless - and here's the strange part - I open up the file and save it. I don't make any changes to it, just save. After saving, I can make the same exact request and it serves up save.php like nothing was ever wrong.

I'm currently exporting from an svn repository (just a simple svn export http://server/repository target command). If I export after not making any changes, the bug re-manifests. If a make a change (to an entirely unrelated page), and commit it to the repository, then export, the bug usually goes away. However, the same thing might happen with two different pages (also unrelated to the changed page), or it may not.

I'm not using any kind of caching (no php caching, browser caching, or apache caching).

SVN versions: 1.6.9 w/ AnkhSVN on a Windows machine (the development machine), 1.4.2 on both the repository machine and the test machine (where I run the export command).

Aside from suspecting svn is where something is going wrong, I have no idea.

Improve this question
4
  • Weird. Is mod_rewrite in effect? As a first step, I'd suggest enabling logging of everything you possibly can in Apache, and see if any of the error messages suggest anything.
    – David Z
    Jun 26, 2010 at 0:37
  • Yes, mod_rewrite is on. I'm still not sure why just saving w/o making any modifications would cause this problem, though...
    – Andrew G
    Jun 29, 2010 at 15:12
  • this almost sounds like some sort of link problem (confused inodes?) on the servers - provide details on the webhosting machines serving view.php and save.php. Try running a 'find /path/to/code -xdev -samefile view.php' (or save.php) and see what you find.
    – user15590
    Sep 5, 2010 at 17:01
  • browser cache? proxies? the act of saving it forces a hard refresh?
    – John Mee
    Nov 2, 2010 at 0:11

3 Answers 3

Reset to default
1

Why don't you try to rename the files. Rename both files, add some kind of prefix and try again. This may get rid of any faulty redirect/inode confusion (maybe).

Make sure none of the caching is enabled. Check your modules in Apache and unload any caching module. Make sure APC extension in PHP is not loaded (phpinfo)

Try using svn checkout instead of svn export. Start testing and when you notice the buggy behaviour do svn stat to see if anything has changed. Technically there should be no difference between checkout and export except that checkout is more usefull as it allows in place updates. But with checkout you want to have something like following in your vhost config.

<LocationMatch "\.svn.*">
 Order deny,allow
 Deny from all
</LocationMatch>

Last but not least, start with fresh HTTP config. Backup config and reinstall your Apache/PHP packages. This should generate default config. Then, add simple config changes to be able to serve the PHP files. Once you can see both files with no problem start testing for your issue. Then gradually start adding config parts from your saved config until it starts failing. The last part that you added is what causes it.

Improve this answer
0

Certianly I've never heard of anything like this despite running several small and medium LAMP sites.

Aside from suspecting svn is where something is going wrong

How hard would to be to check that the contents of save.php has not been replaced with save.php? But that in itself would not explain why it occurs randomly.

Have you sniffed the traffic when replicating the bug to ensure its not due to redirection or caching?

What do the access and error logs show after serving up the wrong content?

C.

Improve this answer
1
  • Unsurprisingly, the access and error logs don't show anything - no errors get generated, and the only indication on the access logs that anything is different is just the size of the returned content. I'll make sure to do lots of sniffing once the bug manifests itself.
    – Andrew G
    Jun 29, 2010 at 16:37
0

I only have a superficial knowledge of mod_rewrite. Regardless of having mod_rewrite, I would recommend deleting both save.php and view.php from SVN, then re-importing them with separate commits. I am going off some knowledge I have gained where the revisions become corrupted and moving them or deleting and re-importing fixes the problem. It is not an elegant (proposed) solution, I know.

I hope this helps.

Thank you,
Zachary

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .