Strange PHP SESSION behaviour, possibly iUI related

Fibo

unread,

Mar 14, 2012, 9:52:28 AM3/14/12

to iphone...@googlegroups.com

Just to be clear: I stumble on a PHP related problem, for which I have not (yet) found a PHP explanation.

So I am exploring that the problem might result from my use of iUI.

Short form: what might lead $_SESSION content to change between several PHP pages?

Background:

From an HTML/javascript/iUI page I am calling PHP scripts A, later B, later C. These scripts are called thru submitting forms with POST.

1 - In A.php I define values in $_SESSION, and luckily they are stil there when later script B is called: this matches the expected session handling.

While in B.php I place some values in the $_SESSION array, eg $_SESSION['my_data']='in Form B';

After setting up these values, check if this worked by displaying the $_SESSION array.

2 - After control returns to the client, script C.php is called... but $_SESSION contents look the same than after script A, ie as if what has happened in B.php... was cancelled or ignored.

Any idea? In which situations do you think this might happen?

Remi Grumeau

unread,

Mar 14, 2012, 10:19:48 AM3/14/12

to iphone...@googlegroups.com

Session lives in the document header, which is refreshed only on page load.

When you load A, it stores $_SESSION.

So A is the page running iUI, doing ajax calls to B or C.

When asking B from A, B is loaded so its header (and PHP session) is updated.

Not A's since it's not reloaded.

So when asking C from A, it uses the session of A, not the one B changed.

Best way to get an updated variables is to:

- reload A so header / session is updated

- use a JS variable in A you update with B ajax call result

Remi

--
You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/iphonewebdev/-/KOnw9NU2f4MJ.
To post to this group, send email to iphone...@googlegroups.com.
To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.

Fibo

unread,

Mar 14, 2012, 10:54:32 AM3/14/12

to iphone...@googlegroups.com

Thx Rémi, I understand now. I was believing session data was alive on the server (eg, session.save_path: /var/lib/php5) , not on the client...

B-(( I was thinking of php session's variables as an easy way to store data in a persistent way, rather than playing with <input and POST amongst my different windows generated by php scripts.

I had some trouble with input/POST and SESSION (fed thru input/POST, but only once for each variable) and, if it had worked, session variable would have solved that.

It I still can't make it thru input/POST, I will probably look at cookies

Remi

To unsubscribe from this group, send email to iphonewebdev+unsubscribe@googlegroups.com.

Remi Grumeau

unread,

Mar 14, 2012, 12:09:02 PM3/14/12

to iphone...@googlegroups.com

On Wed, Mar 14, 2012 at 3:54 PM, Fibo <bernard...@gmail.com> wrote:

Thx Rémi, I understand now. I was believing session data was alive on the server (eg, session.save_path: /var/lib/php5) , not on the client...

They are. PHP is a server side script.

But when loading, the document asks the server for a page. This page comes with its body, but also a header. Body is what you see/written, header is/must be initialized before anything is written.

This is not related to HTML <body> or <head>, a PHP script can render anything (plain text, HTML, image, JSON, RSS, PDF ...)

What you got asking for $_SESSION is what $_SESSION is (on the server) when you ask for A.php.

I'm 99% sure but i might be wrong... someone ?

B-(( I was thinking of php session's variables as an easy way to store data in a persistent way, rather than playing with <input and POST amongst my different windows generated by php scripts.

I had some trouble with input/POST and SESSION (fed thru input/POST, but only once for each variable) and, if it had worked, session variable would have solved that.

It I still can't make it thru input/POST, I will probably look at cookies.

Cookies are part of the header...

OFT: That's the point of websockets for example: it has no header, so no cookie infos, no session infos, ... clearly lighter.

To view this discussion on the web visit https://groups.google.com/d/msg/iphonewebdev/-/oyiwEPIEYQ4J.

To post to this group, send email to iphone...@googlegroups.com.

To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com.

Fibo

unread,

Mar 14, 2012, 8:44:14 PM3/14/12

to iphone...@googlegroups.com

Seems correct, & is coherent. So I'll need torevise my strategy gor data perdistence.
Cookies should be available, as long as I don't try to use them as vehicles PHP -> client.

Fibo

unread,

Mar 15, 2012, 5:58:54 PM3/15/12

to iphone...@googlegroups.com

B-) Solved. I was completely wrong, and the problem I presented was caused, apparently, by my use of session_write_close.

As soon as I removed session_write_close... All was OK.
Thus, what is described at page http://www.php.net/manual/en/function.session-write-close.php
is, at least for my non-fluent English.

A better explanation of the problem, highly coherent with Rémi's guess, is presented at page
http://stackoverflow.com/questions/5130241/php-session-write-close-keeps-sending-a-set-cookie-header

To summarize: never use session_write_close in php scripts called Ajaxly by a client page!

Reply all

Reply to author

Forward