Hi,
Attached is a patch (against HEAD) which adapts the default ("php") session
serializer to serialize the whole array using php_var_serialize instead of
calling it once per element.
This simplifies the serialization code, and allows unicode session keys, or
even ascii keys containing the pipe character.
However it would be a significant BC break, as old serialized session
records would be unreadable after upgrading. We could mitigate this by
providing a script to convert old session files.
It also means the serialized data would be a few bytes larger per key, so
there's definitely some weighing up to do.
Any thoughts?
Arpad
However it would be a significant BC break, as old serialized session
records would be unreadable after upgrading. We could mitigate this by
providing a script to convert old session files.
I would say just a note saying "old session files if they exist will
be unreadable after this change"
Also GC would not clean them up either? That might be the worse thing.
Upgrading should be something people understand could mean downtime or
slight changes like losing session data and it should be an acceptable
loss... I use MySQL for my sessions currently; would the key for the
session be changed then or only the session data? If so, only people
using files would be affected anyway, right?
Hi!
Attached is a patch (against HEAD) which adapts the default ("php")
session serializer to serialize the whole array using php_var_serialize
instead of calling it once per element.This simplifies the serialization code, and allows unicode session keys,
or even ascii keys containing the pipe character.
I think it makes sense. One note: your code allows numeric session keys,
previously not allowed. Not sure if it's important.
However it would be a significant BC break, as old serialized session
records would be unreadable after upgrading. We could mitigate this by
providing a script to convert old session files.
If it would be a problem, we could always keep an old one as "php_old"
for a while for those who need it, just not make it the default.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I think it makes sense. One note: your code allows numeric session keys,
previously not allowed. Not sure if it's important.
This might be important for 32bit<->64bit interaction using serialized data.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
I think it makes sense. One note: your code allows numeric session keys,
previously not allowed. Not sure if it's important.This might be important for 32bit<->64bit interaction using serialized
data.
Although the patch allows numeric keys to be encoded, they're silently
dropped in decoding. Previously they were silently dropped during encoding.
I prefer this way since it saves the overhead of filtering the array first.
If there's an inherent danger in unserializing between 32/64bit int array
keys, this risk is already present in the form of nested arrays (not to say
it's an unimportant consideration). My testing with out of range values on
32bit and 64bit saw nothing unusual, although it revealed a misplaced
zval_add_ref which the attached updated patch fixes.
Incidentally, is there any need (in HEAD) to check EG(symbol_table) in the
decode function, now that register_globals, session_register et al are gone?
Regards,
Arpad