On Thu, March 15, 2007 4:15 am, Richard Quadling wrote: > 1 - It doesn't matter what the server side handler is > (files/user/sqlite/mm/etc), session data is not stored until you do a > session_write_close(). So for a separate process to have access to the > data, the session must be closed.
You could, in theory, write your own "SetSessionData" function which stored into $_SESSION and *also* updated something somewhere immediately, for the external process to read... It would probably suck for large amounts of session data, but could work nicely and solve your problem otherwise. I'm not saying PHP shouldn't be smart enough to only send the one header, as it is already caching other headers and only sending one unless you add that second arg to header() anyway, so all the hooks are there -- Just that you could fix it today instead of waiting on a change to PHP source to happen. > I see this as an easy fix with possible a miniscule performance > increase as the header won't need to be sent when it is not needed. > OOI. It may be a better solution to detect duplicate headers in the > sapi_add_header_ex() function. Maybe. Do whatever is done by the Userland header() function, which buffers headers and only sends one. That's been working for ages. :-) > Please add this little patch as it will mean AJAX with IE and PHP > sessions will all play nicely with each other and there is no need to > add additional userland code to deal with locking as PHP sessions do > EXACTLY what is required. I think you still need locking in PHP Userland for concurrent access to be meaningful to most developers... Otherwise you end up with a race condition in the session save handler. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
