Question

This will be a newbie question but I’m learning php for one sole purpose (atm) to implement a solution–everything i’ve learned about php was learned in the last 18 hours.

The goal is adding indirection to my javascript get requests to allow for cross-domain accesses of another website. I also don’t wish to throttle said website and want to put safeguards in place. I can’t rely on them being in javascript because that can’t account for other peers sending their requests.

So right now I have the following makeshift code, without any throttling measures:

<?php

  $expires = 15;

  if(!$_GET["target"])
    exit();
  $fn = md5($_GET["target"]);
  if(!$_GET["cache"]) {
    if(!array_search($fn, scandir("cache/")) ||
      time() - filemtime($file) > $expires)
      echo file_get_contents("cache/".$fn);
    else
      echo file_get_contents(file);
  }
  else if($_GET["data"]) {
    file_put_contents("cache/".$fn, $_GET["data"]);
  }
?>

It works perfectly, as far as I can tell (doesn’t account for the improbable checksum clash). Now what I want to know is, and what my search queries in google refuse to procure for me, is how php actually launches and when it ends.

Obviously if I was running my own web server I’d have a bit more insight into this: I’m not, I have no shell access either.

Basically I’m trying to figure out whether I can control for when the script ends in the code, and whether every ‘get’ request to the php file would launch a new instance of the script or whether it can ‘wake up’ the same script. The reason being I wish to track whether, say, it already sent a request to ‘target’ within the last n milliseconds, and it seems a bit wasteful to dump the value to a savefile and then recover it, over and over, for something that doesn’t need to be kept in memory for very long.

Answer 1

Every HTTP request starts a new instance of the interpreter; it’s basically an implementation detail whether this is a whole new process, or a reuse of an existing one.

This generally pushes you towards good simple and scalable designs: you can run multiple server processes and threads and you won’t get varying behaviour depending whether the request goes back to the same instance or not.

Loading a recently-touched file will be very fast on Linux, since it will come right from the cache. Don’t worry about it.

Do worry about the fact that by directly appending request parameters to the path you have a serious security hole: people can get data=../../../etc/passwd and so on. Read http://www.php.net/manual/en/security.variables.php and so on. (In this particular example you’re hashing the inputs before putting them in the path so it’s not a practical problem but it is something to watch for.)

More generally, if you want to hold a cache across multiple requests the typical thing these days is to use memcached.