On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman <figureone...@gmail.com> wrote:
> For the umpteenth time, *in what situation must you PUT > multipart/form-data or multipart/x-www-form-urlencoded only to treat it, > semantically, as a POST*? Which UA cannot send a POST? It's like we're > completely upside down on this thread. > If you're PUTing such POSTful content-types for any reason other than > storing the entire resource, you're doing HTTP wrong. Truthfully: if > someone said, "Yeah, so we got into PUT lately, we use it for Ajax form, > er, posts, for, um, speed or something," would you not be like, "Wat?" > The HTTP specification doesn't restrict how the request body is encoded based on the request verb. That is up to the content-type and content-encoding headers. The request verbs themselves are indicative of intent in the request, not necessarily the composition of said request. So we're dealing with decomposition not intent. That part is up to the user not PHP. multipart form data is useful for including both form data and binary data with successive parts. Typically the method applied for this mime in the client UA is POST, but many APIs may apply a PUT request using multipart form. There's no reason to be restrictive of that in PHP if we doesn't break compatibility, I don't think. These are real world problems that people deal with in on the web every day. Here are some sources to demonstrate real world use cases and issues: - https://github.com/symfony/symfony/issues/9226 - https://www.drupal.org/node/1270190 - http://uncorkedstudios.com/blog/multipartformdata-file-upload-with-angularjs - https://bugs.php.net/bug.php?id=55815 Let's face it. The web is a very imperfect place, but it's very tolerance to fault is what makes it work so well. Clearly we don't agree with everything that's done on the web, but that doesn't mean we can't help make PHP a little more useful on the web. > > -- S. >
