> PUT, DELETE, must be available in a single global variable, the > variable name is not important > file_get_contents(‘php://input') - uncomfortably
If the quibble were with file_get_contents(‘php://input') that's not sufficiently uncomfortable to warrant a new superglobal. I assume you mean parsing the contents of php://input into an associative array regardless of the content-type of the HTTP entity-body. However, you're glossing over the semantic difference between POSTing an entity-body and PUTing that same body. multipart/form-data is specified in RFC 1867 as POST-specific, with deliberate notes about expected server behavior. RFC 2388 expands form-data into a general mimetype regardless of transport, and theoretically regardless of HTTP method, but AFAIK there's no equivalent to 1867 that reasonably leads to auto-decoding PUT form-data into an associative array. Rather, the PUT payload has always been designed to _become_ the target resource, as-is. The POST payload is designed to be interpreted via the server's own semantics before changing any resource state. Thus there is a very strong reason to present POST data to the server in an easily accessible and mutable form. Not so for PUT. This doesn't mean PUT payloads must stay opaque to PHP, of course. If there's a need to validate the payload before overwriting the current resource state, that may require that it be passed through some binary image verification, validated against a DTD, or -- indeed -- decoded from multipart MIME into its parts for validation, even if it's the multipart representation that eventually gets stored. Yet if you feel that PUT content should be automatically decoded, you might as well apply this to other multipart content as well -- if I PUT an MHTML file or, as noted before, an RFC 822 e-mail, by this assumption those would also populate the new superglobal. Honestly if it didn't consume any extra resources to always populate, I wouldn't care. But to be unable to avoid decoding every giant multipart payload just because I _might_ want to look at the parts is highly inefficient. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
