views:

22

answers:

1

I have designed a stylesheet/javascript files bundler and minifier that uses a simple cache mechanism. It simply writes into a file the timestamp of each bundled files and compares those timestamps to prevent rewriting the "master file" again. That way, after an application update (here my website), where CSS or JS files were modified, a single request would trigger the caching again only once. This, and all other requests would then see a compiled file such as master.css?v=1234567.

The thing is, under my development environment, every tests pass, integration works great and everything works as expected. However, on my staging environment, on a server with PHP5.3 compiled with FastCGI, my cached files seems to get rewritten with invalid data but only when not requested from the same browser.

Use case:

  • I make the first request on Firefox, under Linux. Everything works as expected for every other requests on that browser.
  • As soon as I make a request on Windows/Linux (IE7, IE8, Chrome, etc) my cache file gets invalid data, but only on the staging server running under FastCGI, not under development!
  • Running back another request on Firefox recaches the file correctly.

I was then wondering, does FastCGI has anything to do with it? I thought browser's clients or even operating systems didn't have anything to do with server side code.

I know this problem is abstractly described, but pasting any concrete code would be too heavy IMO, but I will do it if it can clear up my question.

I have tried remote debugging my code, and found that everything was still working as expected, even the cached file gets written correctly. I saw that when the bug occurs, the file gets written with the expected data, but then gets rewritten back with invalid data after two seconds -after php has finished its execution!-

Is there a way to disable that FastCGI caching for specific requests through a PHP function maybe?

+1  A: 

Depending on your environment, you could look at working something out using .htaccess in Apache to serve those requests in regular cgi mode. This could probably be done with just a simple AddHandler, and Action that points to the cgi directly. This kind of assumes that you are deploying to some kind of shared hosting environment where you don't have direct access to Apache's config.

Since fastcgi persists the process for a certain amount of time, it makes sense that it could be clobbering the file at a later point after initial execution, although what the particular bug might be is beyond me.

Not much help, I know, but might give you a few ideas...

EDIT: Here is the .htaccess code from my comment below

Options -Indexes +FollowSymLinks +ExecCGI
AddHandler php-cgi .php
Action php-cgi /cgi-bin/php5.cgi
tsgrasser
@tsgrasser In contrary, it is helpful. I have partially thought of this but this would lead into some sort of a 'deploying mechanism' for my application, but I like the idea. I may have to resolve into a mini web service facade that launches the optimizer in regular cgi. I am not an expert into the CGI/FastCGI mechanism, do you have a simple example that would serve a PHP file as regular CGI using the .htaccess? (Yes I am on shared host without direct access).
Steven Rosato
In the directory where the suspect script runs, create an .htaccess file and add something like this:Options -Indexes +FollowSymLinks +ExecCGIAddHandler php-cgi .phpAction php-cgi /cgi-bin/php5.cgiCreate a folder in the web root called cgi-binCopy the cgi file from your host's php bin dir into your new cgi-bin dir. Make sure to name it php5.cgi You should be able to find the binary using whereis php5 and looking in the directorys returned. You might be able to symlink to it, however that doesn't work on my host. This may or may not work at first, so this is just a starting point.
tsgrasser