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! Le jeudi 15 mars 2012 01:44:14 UTC+1, Fibo a écrit : > > 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. > > > Le mercredi 14 mars 2012 17:09:02 UTC+1, Remi Grumeau a écrit : >> >> On Wed, Mar 14, 2012 at 3:54 PM, Fibo <[email protected]> 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. >> >> >> >> Le mercredi 14 mars 2012 15:19:48 UTC+1, Remi Grumeau a écrit : >>> >>>> 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 >>>> >>>> >>>> On Wed, Mar 14, 2012 at 2:52 PM, Fibo <[email protected]>wrote: >>>> >>>>> 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? >>>>> >>>>> -- >>>>> 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<https://groups.google.com/d/msg/iphonewebdev/-/KOnw9NU2f4MJ> >>>>> . >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> iphonewebdev+unsubscribe@**googlegroups.com<iphonewebdev%[email protected]> >>>>> . >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/iphonewebdev?hl=en<http://groups.google.com/group/iphonewebdev?hl=en> >>>>> . >>>>> >>>> >>>> -- >>> 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/-/oyiwEPIEYQ4J. >>> >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/iphonewebdev?hl=en. >>> >> >> Le jeudi 15 mars 2012 01:44:14 UTC+1, Fibo a écrit : > > 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. > > > Le mercredi 14 mars 2012 17:09:02 UTC+1, Remi Grumeau a écrit : >> >> On Wed, Mar 14, 2012 at 3:54 PM, Fibo <[email protected]> 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. >> >> >> >> Le mercredi 14 mars 2012 15:19:48 UTC+1, Remi Grumeau a écrit : >>> >>>> 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 >>>> >>>> >>>> On Wed, Mar 14, 2012 at 2:52 PM, Fibo <[email protected]>wrote: >>>> >>>>> 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? >>>>> >>>>> -- >>>>> 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<https://groups.google.com/d/msg/iphonewebdev/-/KOnw9NU2f4MJ> >>>>> . >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> iphonewebdev+unsubscribe@**googlegroups.com<iphonewebdev%[email protected]> >>>>> . >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/iphonewebdev?hl=en<http://groups.google.com/group/iphonewebdev?hl=en> >>>>> . >>>>> >>>> >>>> -- >>> 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/-/oyiwEPIEYQ4J. >>> >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/iphonewebdev?hl=en. >>> >> >> Le jeudi 15 mars 2012 01:44:14 UTC+1, Fibo a écrit : > > 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. > > > Le mercredi 14 mars 2012 17:09:02 UTC+1, Remi Grumeau a écrit : >> >> On Wed, Mar 14, 2012 at 3:54 PM, Fibo <[email protected]> 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. >> >> >> >> Le mercredi 14 mars 2012 15:19:48 UTC+1, Remi Grumeau a écrit : >>> >>>> 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 >>>> >>>> >>>> On Wed, Mar 14, 2012 at 2:52 PM, Fibo <[email protected]>wrote: >>>> >>>>> 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? >>>>> >>>>> -- >>>>> 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<https://groups.google.com/d/msg/iphonewebdev/-/KOnw9NU2f4MJ> >>>>> . >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> iphonewebdev+unsubscribe@**googlegroups.com<iphonewebdev%[email protected]> >>>>> . >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/iphonewebdev?hl=en<http://groups.google.com/group/iphonewebdev?hl=en> >>>>> . >>>>> >>>> >>>> -- >>> 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/-/oyiwEPIEYQ4J. >>> >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/iphonewebdev?hl=en. >>> >> >> Le jeudi 15 mars 2012 01:44:14 UTC+1, Fibo a écrit : > > 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. > > > Le mercredi 14 mars 2012 17:09:02 UTC+1, Remi Grumeau a écrit : >> >> On Wed, Mar 14, 2012 at 3:54 PM, Fibo <[email protected]> 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. >> >> >> >> Le mercredi 14 mars 2012 15:19:48 UTC+1, Remi Grumeau a écrit : >>> >>>> 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 >>>> >>>> >>>> On Wed, Mar 14, 2012 at 2:52 PM, Fibo <[email protected]>wrote: >>>> >>>>> 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? >>>>> >>>>> -- >>>>> 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<https://groups.google.com/d/msg/iphonewebdev/-/KOnw9NU2f4MJ> >>>>> . >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> iphonewebdev+unsubscribe@**googlegroups.com<iphonewebdev%[email protected]> >>>>> . >>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/iphonewebdev?hl=en<http://groups.google.com/group/iphonewebdev?hl=en> >>>>> . >>>>> >>>> >>>> -- >>> 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/-/oyiwEPIEYQ4J. >>> >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/iphonewebdev?hl=en. >>> >> >> -- 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/-/K6c42PhwA3YJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.
