Req #54383 [Com]: extend the usage of session_encode/session_decode
Edit report at https://bugs.php.net/bug.php?id=54383edit=1 ID: 54383 Comment by: arraypad at gmail dot com Reported by:tyra3l at gmail dot com Summary:extend the usage of session_encode/session_decode Status: Open Type: Feature/Change Request Package:Session related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The problem with this is that we currently expect the (possibly custom) serializer to work directly on the $_SESSION array. Changing this would be a big BC break in the session API. Previous Comments: [2011-03-25 16:16:33] tyra3l at gmail dot com Description: I always wondered about the rationale about the session_encode/decode in it's current form, but Chris Shiflett's blogpost made me to open this bugreport: http://shiflett.org/blog/2011/mar/php-session-debugging I would propose two changes: - add a new optional array argument for session_encode, if it is passed, then encode that instead of the $_SESSION array. - add a new optional boolean argument for session_decode, if that sets to true (default is false), then the decoded session array is returned instead of inserted to $_SESSION obviously the documentation about the return variable for session_decode should also be updated to reflect this change. this should be backward compatible change, but it would allow us to encode/decode an arbitary serialized session without the need to save and reload the contents of the current $_SESSION array. -- Edit this bug report at https://bugs.php.net/bug.php?id=54383edit=1
Req #54383 [Com]: extend the usage of session_encode/session_decode
Edit report at https://bugs.php.net/bug.php?id=54383edit=1 ID: 54383 Comment by: tyra3l at gmail dot com Reported by:tyra3l at gmail dot com Summary:extend the usage of session_encode/session_decode Status: Open Type: Feature/Change Request Package:Session related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I don't see your point. as I mentioned, this change would be backward compatible, because by default, the behavior would be the same, but it would be possible to encode/decode the session from/to an arbitary variable. Tyrael Previous Comments: [2011-07-02 19:23:39] arraypad at gmail dot com The problem with this is that we currently expect the (possibly custom) serializer to work directly on the $_SESSION array. Changing this would be a big BC break in the session API. [2011-03-25 16:16:33] tyra3l at gmail dot com Description: I always wondered about the rationale about the session_encode/decode in it's current form, but Chris Shiflett's blogpost made me to open this bugreport: http://shiflett.org/blog/2011/mar/php-session-debugging I would propose two changes: - add a new optional array argument for session_encode, if it is passed, then encode that instead of the $_SESSION array. - add a new optional boolean argument for session_decode, if that sets to true (default is false), then the decoded session array is returned instead of inserted to $_SESSION obviously the documentation about the return variable for session_decode should also be updated to reflect this change. this should be backward compatible change, but it would allow us to encode/decode an arbitary serialized session without the need to save and reload the contents of the current $_SESSION array. -- Edit this bug report at https://bugs.php.net/bug.php?id=54383edit=1
Req #54383 [Com]: extend the usage of session_encode/session_decode
Edit report at https://bugs.php.net/bug.php?id=54383edit=1 ID: 54383 Comment by: arraypad at gmail dot com Reported by:tyra3l at gmail dot com Summary:extend the usage of session_encode/session_decode Status: Open Type: Feature/Change Request Package:Session related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: The BC break would be in the session serializer API. Serializers are expected to read directly from $_SESSION - the PS_ENCODE_LOOP macro is provided to facilitate this but it may not be used - and to write back to $_SESSION. Again we provide php_set_session_var() to facilitate this and the two serializers we bundle use it, but custom serializers may not. We could provide this feature without the BC break by adding a separate interface, but it wouldn't work for any custom serializers (igbinary for example) until they were updated. I think the current interface is poor, but I'm not convinced that adding another interface is the answer - I'd rather fix it and accept the BC break, but that would have to wait for a new major version. Previous Comments: [2011-07-02 19:32:17] tyra3l at gmail dot com I don't see your point. as I mentioned, this change would be backward compatible, because by default, the behavior would be the same, but it would be possible to encode/decode the session from/to an arbitary variable. Tyrael [2011-07-02 19:23:39] arraypad at gmail dot com The problem with this is that we currently expect the (possibly custom) serializer to work directly on the $_SESSION array. Changing this would be a big BC break in the session API. [2011-03-25 16:16:33] tyra3l at gmail dot com Description: I always wondered about the rationale about the session_encode/decode in it's current form, but Chris Shiflett's blogpost made me to open this bugreport: http://shiflett.org/blog/2011/mar/php-session-debugging I would propose two changes: - add a new optional array argument for session_encode, if it is passed, then encode that instead of the $_SESSION array. - add a new optional boolean argument for session_decode, if that sets to true (default is false), then the decoded session array is returned instead of inserted to $_SESSION obviously the documentation about the return variable for session_decode should also be updated to reflect this change. this should be backward compatible change, but it would allow us to encode/decode an arbitary serialized session without the need to save and reload the contents of the current $_SESSION array. -- Edit this bug report at https://bugs.php.net/bug.php?id=54383edit=1
