php maintaining state

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.

score 2 · Answer 1 · answered Aug 07 '12 at 00:30

2

php is done from a per-connection basis. IE: each request for a php file is seen as a new instance. Each instance is ended, generally, when the connection is closed. You can however use sessions to save data between connections for a specific user

For basic use of sessions look into:

session_start()
$_SESSION
session_destroy()

answered Aug 07 '12 at 00:30

SReject

3,774
1
25
41

Well that answered that for me straight-up. :) I'm wondering what's the best way to maintain variables across scripts. I've been eyeing the 'serialization' stuff on the php.net references, but at the risk of sounding a dummy i'm having trouble understanding how to use it (doesn't help that I see the example pass arguments to a function the document declared didn't accept any arguments). Is there a more lucid tutorial for this? – Rob F Aug 07 '12 at 00:36
look at php.net and remember to hit the check to the left of the above answer for me :D – SReject Aug 07 '12 at 00:37
... I just said the php.net stuff wasn't answering it for me. – Rob F Aug 07 '12 at 00:41
Oh sorry, I think I missed a line while reading your response. – SReject Aug 07 '12 at 00:43
1

`the best way to maintain variables across scripts` is literally using $_SESSIONS. $_SESSION is a variable - accessible just like $_POST["var"] - except its contents will be stored serverside and attached to a php session cookie that will be put into your clients browser. – Alex Lynch Aug 07 '12 at 00:43
1

@AlexLynch I wouldn't say it's the best way. But it is the most prodominate. With each session_start() the sessions file is locked until either the session is closed or destroyed. This can cause new connections to wait, and timeout, for applications such as COMET – SReject Aug 07 '12 at 00:45
What if the variable is common to all clients? If 10 users click a button that activates 10 calls to my get.php for the same target, that's 100 http get requests sent to the server, and that server will see them all coming from the same ip address. – Rob F Aug 07 '12 at 00:53
Is there a way I can use sessions to have the script relaunch itself with the same state, so that the client will just wait a bit longer rather than have to initiate another request? – Rob F Aug 07 '12 at 00:53
sessions aren't stored by IP. The server creates a unique id, then sends that ID as a cookie for the client to store. Then when the client reconnects, it will send that cookie back to the server – SReject Aug 07 '12 at 00:56
That has nothing to do with what I said, though. – Rob F Aug 07 '12 at 01:21

poolie · Accepted Answer · 2012-08-07T01:56:49.970

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.

Thanks for that. This particular script won't be accepting any arguments that need securing (the parts of the page the javascript retrieves will be read-only--hence why it only caches if a certain argument is present, so as to pass only part of the retrieved page back to the script for caching purposes), but I'll keep it in mind for the future. — Rob F, Aug 07 '12 at 00:39

php maintaining state

2 Answers2