This vendor tree MIME type registration application discusses the data
format emitted by PHPs "serialize()". It is no longer in use only within
there; some independent implementations exist (evtl. becoming an exchange
format).
Now that doesn't require a MIME Type per se, but people also started
pushing data in this format through the wires ("me too!"). See also
"PHP-RPC" in [http://geri.cc.fer.hr/~ivoras/web2/papers/phprpc.pdf]
-- not the best example, but at least highlights the necessarity of
a MIME Type - else people go by text/html.
* I guess by RFC2048 the PHP group [//php.net] should have filed this
rather, but if they had any interest in it they'd already done long
before. The vendor name was more accurately "zend" or "phpnet", but
simply "application/vnd.php.serialized" looks much better.
* Not all too sure if this MIME subtype should have the trailing 'd'
or simply be called "/vnd.php.serialize". The "/...d" version however
seems to match better with "/x-www-form-urlencoded".
* I've included an as-short-as-possible description, cause Google didn't
found anything worth getting referenced, and I'm really not aware of
an official format spec.
* Btw, "Person & email address to contact for further information" could
be a mailing list instead, couldn't it?
hope the wording is 'good enough' for a vnd. subtype :)
mario
---------------------------------------------------------------------
MIME media type name: application
MIME subtype name: vnd.php.serialized
Required parameters: NONE
Optional parameters:
version=x.y.z
SHOULD be added in responses (not in Accept: headers [RFC2295])
to indicate which PHP interpreter version the data was
compacted by. This is useful to identify and eventually work
around bugs (format violations) from earlier implementations.
Encoding considerations: BINARY
As per current use, contents assigned this MIME Type should be
considered to be in the ISO-8859-1 (Latin-1) character set, so
that they also may contain arbitrary non-printable characters,
binary octets.
Transport channels not capable of handling raw 8 bit without data
corruption SHOULD therefore apply a Transfer-Encoding of "base64"
or something similar.
Security considerations:
Implementations SHOULDN'T attempt to reproduce more complex data
types like objects, file descriptors, function bytecode and
pointers, because most of this was typically of little use if the
received data came from a remote machine or even from a different
programming language.
For optimal security only the basic data types are to be extracted
and messages fully be rejected as soon as unknown data type
identifiers were detected.
Strongly typed languages with fixed-length variable data storage
should additionally take care not to expand entities of the format
described herein beyond memory boundaries; even if none of the
mentioned types is that difficult to decipher.
Interoperability considerations:
The specified format is meant to transport data in a machine-
independent representation, and is especially freed from byte-
ordering issues, because all integer types pass in string
representation. However, there is no surety that the described
data representation could be used by every possible system,
especially since it originally was made for use by interpreted
languages only.
Published specification:
To date there is no openly published specification of this data
representation format. For reference the original implementation
in [http://cvs.php.net/php-src/ext/standard/var.c#click-display]
or even better the Perl implementation by Scott Hurring available
under [http://hurring.com/code/perl/serialize/] can be reviewed.
A terse documentation of how the basic data types are to be
encoded is however included here.
Format description:
Data is compacted into string representation by bailing out
chunks containing a type identifier (one letter) an optional
length/count field (for strings and arrays) and an optional
value (optional because the NULL/undef type does not require
one for obvious reasons), all separated by colons and ended
with a semicolon in most cases.
<app/vnd.php.serialized#TEXT> = (<data>) *1
<data> = ( <undef> | <boolean> | <int> | <float>
| <string> | <hash> | <strangethings> )
<undef> = 'N;'
<boolean> = ( 'b:0;' | 'b:1;' )
<int> = 'i:' ['-'] <digit>*1 ';'
<float> = 'd:' ['-'] <digit>*1 '.' <digit>*1 ';'
<string> = 's:' ( <LENGTH> ) <:"> <text> <";>
<text> is the string this entity represents after
serialization. It has exactly <LENGTH> characters and is
enclosed here by two quote marks. No escaping is to be
applied, and the receiver shouldn't have to decode it.
<hash> = 'a:' ( <COUNT> ) ':{' (<data> <data>)*COUNT '}'
Where <COUNT> is a positive integer (as string) matching
the number of key<data>+value<data> pairs in between the
curly braces.
As an exception the string representation of an array or
hash does not carry a final semicolon (unlike all basic
data types).
Other known data type identifiers are "O" for objects, "R" for
references and "r" for object references. They are not further
mentioned here, because they are of little use for exchanging
data across servers as outlined in the Security considerations
section.
Applications which use this media type:
[http://www.php.net/]
PHP interpreter with original implementation
[http://hurring.com/code/perl/serialize/]
Perl 'serialize.pm' by Scott Hurring and others
[http://php.net/serialize#41948]
serialize methods for Ecma/JavaScript types by Iván Montes
Additional information:
Magic numbers: NONE
File extensions: NONE
Macintosh File Type Codes: NONE
Object Identifiers or OIDs: NONE
Person & email address to contact for further information:
Mario Salzer
<[EMAIL PROTECTED]>
Intended usage: COMMON
This data format is in heavy use for temporarily storing data to
disk to keep it beyond a single application run.
Recently it also started to get used for transportation of data
via HTTP, as lightweight alternative to SOAP and also XML-RPC.
By including the original representation types of transcoded data,
it can be used advantageous to "multipart/form-data" and of course
the more simple "application/x-www-form-urlencoded". It's not only
much simpler and faster due to less requirements on escaping, but
also indirectly allows for validation (data types).
Author/Change controller:
Mario Salzer
<[EMAIL PROTECTED]>
Since this registration happened on deputy of the vendor,
it's only senseful to transfer 'change control' to
<[EMAIL PROTECTED]> on request.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
