Strange difference when cookie disappears from $_REQUEST in HTTP vs. WAP

(This issue is more to do with how PHP interacts with HTTP/WAP than
with how PHP interacts with MySQL, hence posting to the PHP
newsgroup instead of the MySQL newsgroup this time around.)

I have no idea why this should happen. It seems contrary to the PHP
language. But it's the observed behaviour, which caused a bug in my
tinyurl.com/Portl1 until I programmed around it.

The relevant part of my code was this:
<?php
$cookey = 'session';
$bool1 = array_key_exists($cookey,$_REQUEST);
if (!($bool1 === true)) { die("You don't have a session cookie."); }
$sessval = $_REQUEST[$cookey]; // Get old cookie value before erasing it
setcookie($cookey, "", mktime(12,0,0,1, 1, 1990)); // Erase it now!
?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head><title>Logging out</title></head>
<body>
Header has been generated to destroy your login session cookie, but we also
need to formally terminate your session in the database ...
<?php
require("g3448941383.php"); // Confidential globals that vary by host
require("globs1.php"); // Derived globals using same pattern everywhere
require("funs1.php"); // Define functions used in multiple scripts
qStartTime();
qConSelUse();
qCheckSession();
...

Inside funs1.php:
function qCheckSession() {
global $myG;
$key1 = 'session';
$bool1 = array_key_exists($key1,$_REQUEST);
if (!($bool1 === true)) { timeDie("You don't have a session cookie."); }
$sessval = $_REQUEST[$key1];
...

When accepting HTTP connections, the saved value of $sessval in the
main code, before issuing the header to delete the cookie, wasn't
really needed, because $_REQUEST retained the *original* value of
GET+POST_COOKIE through to the end of this script. It's only the
*next* HTTP transaction where the client (browser) no longer has
the cookie so it doesn't show up in $_REQUEST . So the code for
qCheckSession could ask for it again and get it just fine. The
saved value in the main program was used only for debugging echos,
and was a dunzell at this point, or so I thought.

But when I ran the same script from a cellphone, I got the error
"You don't have a session cookie.", because somehow $_REQUEST had
already **lost** that cookie value during the very same HTTP (WAP)
transaction where the header had been set up to delete that cookie.

I didn't bother to check whether $_COOKIE had also lost the cookie
value, but I suspect that's true. I just went ahead and changed the
code to pass an optional parameter to qCheckSession which is NULL
for most calls where the session cookie hasn't yet been deleted
because we aren't logging out in this script, but in this logout
script I pass the saved value of the session cookie and use that
instead of checking $_REQUEST for it. The new code is:

... (snipped unchanged code)
qCheckSession($sessval); // Bugfix 2009.Jun.15: On cellphone cookie gone now
...

function qCheckSession($sessval = null) {
global $myG;
echo "<br>qCheckSession entry, sessval: [$sessval]<br>\n";
?><a href="#showcred">skip</a><?php
// echo "checkSession...";
if (!$sessval) {
$key1 = 'session';
$bool1 = array_key_exists($key1,$_REQUEST);
if (!($bool1 === true)) { timeDie("You don't have a session cookie."); }
$sessval = $_REQUEST[$key1];
echo "<br>From request now, sessval: [$sessval]<br>\n";
}
...

Now it works on both regular HTTP connections and cellphone (WAP)
connections, using the saved value (passed by optional parameter)
instead of the current value of the session cookie in both cases
even though for HTTP it's redundant.

The trace statements show clearly that in all cases except logout,
the parameter is null and the session cookie value is gotten live
within qCheckSession, while in case of logout the session cookie
value is passed by parameter and the code to look at $_REQUEST from
inside qCheckSession is not executed.

Now can anybody explain why the value of $_REQUEST doesn't show the
cookie that existed at the start of the HTTP/WAP transaction, that
not only was the cookie deleted in the client (on order of the
header) but it was immediately deleted from $_REQUEST also? For
example does WAP break each HTTP transaction into two separate
client/server exchanges, first to send the URI and get back the
HTTP header, and *then* to upload the current cookies and GET and
POST parameters, so the *new* version of cookies gets uploaded,
whereas HTTP does it all in one transaction, so the *old* version
of cookies gets uploaded? That's the only explanation I can think
of that makes any sense to me, or a variation where GET and POST
parameters are sent immediately with first half-transaction but
cookies don't get sent until second half. But I'd like an expert to
confirm my guess or enlighten me as to what really happens.

Anyway, before I fixed the bug, when I tried a cellphone logout,
the cookie would be deleted but the script would die and so the
later code to mark the MySQL record for this session as ended would
never get executed, so with the cookie gone there was no way for
the client to ever try the logout again, so not only would the
session persist forever but the client was stuck in a bug situation
with no login cookie hence no access to the still-active session.
Fortunately this wasn't a major problem, because during original
development of the code I frequently reloaded Web pages or jumped
around in the history so I commonly left sessions orphaned, so
early on I made the first order of business at login time to check
if there were any orphaned sessions and mark (in the db) each as
ended before starting the new session. So at worst with the bug the
user had a dead Web page and had to press the browser's back button
repeatedly until he/she was all the way back to the screen before
login, and then on next login view a screen full of annoying
messages about terminating the orphaned sessions. So that's why I
waited until everything was fixed before investigating this bug and
fixing it.

So now tinyurl.com/Portl1 works on both cellphones and regular Web
browsers, with logout on cellphones working properly for the first
time as of a few minutes ago, everything else working already last
night.
.

Quantcast