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

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
(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 until I programmed around it.

The relevant part of my code was this:
   $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!
<head><title>Logging out</title></head>
Header has been generated to destroy your login session cookie, but we also
need to formally terminate your session in the database ...
   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

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 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

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

Robert Maas, wrote:
Quoted text here. Click to load it

Why are you going to all these gyrations and not just using the built in
PHP session support?  And why use $_REQUEST?  If this has been stored in
a cookie, you need to be using $_COOKIE - $_REQUEST can be faked too easily.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

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

On Jun 16, 8:51=A0am, (Robert Maas, ) wrote:
Quoted text here. Click to load it
Quoted text here. Click to load it

Are you sure it was the second occurrence of the same message? I'd
have gone with different messages for different points in the code.

Quoted text here. Click to load it


Further, there are a lot of hacks and non-compliant WAP gateways out

I'd recommend you try it again in the original form but logging every
request header.



Site Timeline