On Fri, Aug 19, 2011 at 2:31 PM, Arpad Ray <array...@gmail.com> wrote: > On Fri, Aug 19, 2011 at 1:04 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: >> this could still cause problems, as pointed out before (when you >> change your handler, or when you pass serialized data between >> different php installs, etc.), so I really like what Kiall Mac Innes >> suggested: prefix the data with the serializer identifier. >> if it is missing, then it was serialized with the old method, if it >> is present, the appropriate method should be used, if the serializer >> ident is there but unknown, then exit with a fatal error telling the >> user that the custom handler is missing. > > This came up when we discussing changing the default session > serialization format a while ago. A prefix is a nice idea but care > would have to be taken not to collide with any of the bytes which are > valid for the current format to start with. > > Might be more of a curiosity than anything useful, but IIRC > unserialize() currently ignores everything after the end of the data. > >> the downside would be that if you want to serialize/unserialize the >> data outside of php, your implementation should take care of this >> prefix. >> just a wild idea, but maybe useful: >> instead of creating a prefix, we could serialize the passed data with >> the given(php, igbinary, etc.) handler, then wrap the whole stuff into >> an array which holds the name of the used handler and the serialized >> data, and serialize this array with the old(php) serialize method. >> this way the datablob would be always a valid serialized string, and >> would be easier to get the serialize method than with the prefixing. > > If my old app couldn't read some newly serialized string, I'd rather > it failed hard than apparently succeed but have the wrong data. >
http://php.net/unserialize In case the passed string is not unserializeable, FALSE is returned and E_NOTICE is issued. so if you unserialize from php, my suggestion would fail harder. when you unserialize it from another mean (parsing it on your own, or from a different language), you are right, it would produce a valid but different result what you would expect, but this could be documented, and I don't think that that many users do this, and maybe they are using json/bson/igbinary already. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
