Corruption of data in a SESSION variable

PHP
1

I’ve been developing a new site with both a localhost and publically hosted test site. They both work as expected.

Today I uploaded the site to its production location, and for the most part it works fine. However, I have a problem with a query string stored as a SESSION variable which is garbled when retrieved.

The code on both the dev and live sites is supposed to be the same (I’ve uploaded to both from my localhost to make sure), but it seems to be working differently (I know that’s supposed to be impossible).

The $_GET query string is saved to the SESSION for later retrieval

For this example the query string was:

"?et[0]=ALL&loc[14]=SW&save=eatg&eatg=Search"

On the dev site (holidaymullandiona.com) the SESSION var looks like:-

get|s:50:"et%5B0%5D=ALL&loc%5B14%5D=SW&save=eatg&eatg=Search"

When retrieved it works fine, and returns the same data as before.

When I store the same $_GET query string on the live site (holidaymull.co.uk), it’s the same at first, but when retrieved becomes:-

get|s:66:"et%25255B0%25255D=ALL&loc%25255B14%25255D=SW&save=eatg&eatg=Search"

which when used again as a query string gives a rubbish result, of course. I’m asking myself: Where do all the ‘2525’ come from ? Is it some double encoding ?

I cannot yet work out why it should be treated differently on two sites both hosted with the same ISP (probably on the same server), with the same PHP version (5.2.9). The obvious answer would be that the code is different, and I’m constantly checking for that (so far without result).

Any other suggestions, please ?

2

Thank you. I’ve been working along those lines since my last, but so far not cracked it. Nothing yet explains why it’s OK on one domain and not the other. However, if I can resolved the code/decode problem it should no longer matter.

I tried urlencode(), but it led to a similar problem with ‘&’, becoming first ‘&’ which is OK, and then being encoded again and becoming ‘&’ at which point MySQL died. But this at least ofered a clue that double encoding was the problem. Maybe I need to try again with urldecode() as well.

I’ve also tried htmlspecialchars, htmlentities and http_build_query in various mixes.

Essentially I’m trying ot do three things:

  1. Store the $_GET search string in the SESSION so I can go back to the same search later
  2. Compare any new $_GET with the stored value, to see if it’s a new search
  3. Parse the $_GET string and save the result in a database so I know what’s been searched for, and how often.

It was all working well until I uploaded my production site at the same ISP (but I suspect now to a different server).

I continue to work on it, and any suggestions for code/decode combinations are welcome.

3

Thank you both for your thoughts.
John: I’m already using some encoding (along the lines you suggest) for storing the $_GET in the SESSION. Some coding variants make matters worse by repeatedly encoding ‘&’, so you get first ‘&’, then ‘&’ at which point the query fails and there’s a MySQL error message.
StartLion: No doubt I could parse the $_GET string, but it wouldn’t be straight-forward, as it varies in content and length according to the search performed. This wasn’t necessary on the development site.

What I need to find out is why the same scripts perform differently in the two hosted locations. If you have a moment you can see it working correctly at [=ALL&loc[14]=SW&save=eatg&eatg=Search"]http://www.holidaymullandiona.com, and incorrectly at [URL=“http://www.holidaymull.co.uk?et[0]=ALL&loc[14]=SW&save=eatg&eatg=Search”]http://www.holidaymull.co.uk](http://www.holidaymullandiona.com/?et[0).

In the first case, the SESSION string is displayed for debugging. You can see the ‘get’ with its square brackets coded as %5B (opening) and %5D (closing). Then click ‘Add to Shortlist’ on one of the listings displayed. The display will refresh, but the listings will be the same (just three), and the ‘get’ in the SESSION string will be unchanged.

In the second case the SESSION string isn’t displayed because this is meant to be a production site, so check out the query string on the URL in your browser address bar. Then click ‘Add to Shortlist’ on one of the listings displayed, and check out the URL again. It has mysteriously acquired some extra ‘25’ characters on the square brackets (%255B etc.), so now the query is garbled, and there are fifteen listings displayed.
Every time you go round the ‘loop’ between ‘View Shortlist’ and ‘View Search Results’ there’s an extra ‘25’ added to all the square brackets. (%25255B…%2525255B etc.).

If I only knew why !

4

Try using these functions:


 
 $_SESSION['sql'] = htmlentities( $sql );
 $sql      = html_entity_decode( $_SESSION['sql'] );

.

5

25 is the % character, so it would seem you are not decoding before re-encoding? That is, urlencode(‘[’) gives %5B. urlencode(‘%5B’) gives %255B … %2525252525255B

6

Why not parse the variables into the session array? In other words… why not break the -variable- string into it’s component -variables- and store them in the thing designed to hold -variables-?