> The HTTP specification doesn't restrict how the request body is encoded > based on the request verb.
I never said it did... please don't put words in my mouth. As Will notes, you're sidestepping the point, which standards-savvy people have been driving at for years: the semantic differences (== intent, == meaning) among HTTP methods. HTTP specifications *do* define -- in your words, "restrict" -- the intended disposition of the entity-body based on the HTTP method. The methods *do* distinguish whether the entity-body is intended as a precomposed resource to be stored at the request-URI (PUT) -- or whether it may contain key-value strings, multipart MIME data, or arbitrary text and/or binary data ranges (POST) which must be interpreted by application code at the request-URI (which must itself exist) as they have no inherent final disposition. It's easy to certify the semantics in your lab. Set up a capable web server with no preprocessor at all (no PHP, no SSI, nothing). Choose a URI that currently returns a 404, like /test.abc. PUT a well-formed multipart/form-data body to that URI. What you will get is the entire multipart stored within the filesystem at the mapped URI. And provided the server's file extension <-> MIME mappings are consistent, you'll then be able to GET the file as multipart/form-data. Now POST that body to another nonexistent URI. You'll get a 404 or 405. Full stop. This core difference is really not that hard to understand, and there's no reason for PHP to act, stupidly, like it it isn't there (as in make-people-dumber stupid, not make-life-easy stupid). > multipart form data is useful for including both form data and binary data > with successive parts Of course. Multipart MIME is also key to the modern e-mail ecosystem. And, similarly, multipart e-mails are kept as opaque as possible in transit. Antivirus and spam scanners need to peek inside multipart mail, but they don't decompose them and put the parts back on the wire separately, because that is not the meaning of "transfer this e-mail." Neither do end-user apps aim to decompose MIME messages when they're idling in a message db, because that's not the meaning of "save this e-mail." On the other hand multiparts *are* intended to be decomposed by mail apps when a user opens them: in that case, there's a clear semantic justification for expanding the contents for the user: "read this e-mail." In sum, "multipart is useful" is quite obviously true, but it's a straw man, as it does not respond to the question about expanding multipart entities in all contexts. > but many APIs may apply a PUT request using multipart form People do dumb things. You haven't answered why they would fixate upon PUT, since they cannot possibly lack support for POST. What, now for the umpteenth++ time, is the technical/business/personal justification for this design, with POST available? Again this whole debate is upside down. People have to *choose* to use PUT, even in cURL. It doesn't happen by accident. It's not the XMLHttpRequest default. It can't happen from an HTML form. Why are they doing it? > https://github.com/symfony/symfony/issues/9226 If you read that report carefully you will see that it starts with people name-dropping POST and PUT (because they don't understand the difference), including bugs that appear to deal with POST alone. Then, the feature request that does appear PUT-related is shot down by the Symfony maintainers. Obviously, it wasn't wontfixed because it couldn't be done, but because there was insufficient cause, despite the initial claim that Symfony's update API was broken. > https://www.drupal.org/node/1270190 A wontfix "bug" report that doesn't even try to justify why PUT would be used, only that it doesn't work. If a newbie confuses POST and PUT when creating an Ajax object, is that a bug on the server? > http://uncorkedstudios.com/blog/multipartformdata-file-upload-with-angularjs There's no mention *at all* in this post of a need for PUT, just a note that Angular applies the same default content-type to POST and PUT. > https://bugs.php.net/bug.php?id=55815 I see no compelling use case here, only an unsourced claim that "every RESTful interface" would make use of this feature, which would be better phrased "one particular not-at-all-RESTful interface." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
