EDIT I just realized that I must have had a massive brain fart while writing the abbreviated code sample. See, I’m using smarty. Thus, I’m actually already using Kips’s solution, because smarty displays after the session is saved
I’ve been working on implementing a resource manager (for condensing, compressing and minifying CSS & JS) for a PHP site I’m working on and have run into an awfully strange problem. So when a user navigates to index.php, files are added to a resource manager object, which combines them into a single file and are included in the page via either <script src="resource.php?id=123&ext=.js"> or <link href="resource.php?id=123&ext=.css" />
What it basically boils down to is that a file path is stored in a session on the accessed page and read from the session on the resource page. In FF, this works perfectly fine. In IE and Chrome, it does not.
Here’s a much-abbreviated code sample:
index.php
<?php
session_start();
//Do a ton of stuff
//Including adding several files to the resource object
//Add the resource links to the head
$smarty->append('headSection','<link href="resource.php?id=<?=$resourceID?>&type=.js" />');
</head>
//Save the resource file which:
// - Outputs the file
// - Saves a reference to it in session
$_SESSION[$resourceID] = $file;
//Let Smarty display
$smarty->display($templateFile);
?>
resource.php
<?php
readfile($_SESSION[$_GET['id']] . $_GET['type']);
?>
What it seems like to me is that FF waits for an entire page response before making any new requests to the resources required by the page, while IE and Chrome function by starting a new request the second it is encountered. Due to this, this error basically boils down to a race condition.
Can anyone confirm that this is indeed the way it works? And if so – how would I work around it?
Edit: After the update to your question, then I am not surprised that you are getting a race condition. I don’t know why it is working in Firefox, but IE and Chrome are certainly not doing anything illegal by requesting the resources early. One way you could resolve this is with output buffering. At the top of your index.php file, you can add:
This kills two birds with one stone, by: a) making sure that output is buffered, so the browser doesn’t see the file until the whole page has been generated; and b) saving you and your users bandwidth by using gzip compression.
Previous answer: That doesn’t seem to make sense. Cookies can only be set in the header, which happens before any page content is loaded. So the browser requests index.php, and the PHPSESSID cookie is set in the header. Then the page content is delivered.
I don’t have access to a machine with PHP at the moment, but the following might help to test your theory.
test1.phpsets a session variable, but then takes 30 seconds to completely finish loading. Meanwhile,test2.php(a CSS file) will try to use that session variable as the text color. The text will show up red if the session could be read from test2, or black (default color) otherwise.test1.php
test2.php