> Specifically, parsing the form data and populating it somewhere accessible > to the user as it is today in $_POST and making any binary upload available > in $_FILES or some other fashion. Ideally, making handling PUT more > consistent with the way PHP handles POST.
OK, the first definition: "handling" means parsing multipart/form-data automatically into form field names and values. And again there are specific documents that expect this to be done for POST (and understandably so) but no such documents for PUT. Which means you want PUT to act as if it were as formally defined as POST. Which is where we started from: you are transplanting a standard from one method to the other. This doesn't mean you are violating an extant standard, it just is very, very far from compelling. And your best justifications for a present-tense need were wontfixes submitted by relative newbies. > First of all, RFC 1867 is not a standard. It's an experimental protocol > definition. Oh nonsense. You know very well that RFC 1867 conformance is an industry standard for file uploading When 2388 says "originally set out in [RFC1867] and subsequently incorporated into [HTML40]" it is not treating 1867 as some fringe document. Non-HTML uploaders (Flash/Java/Silverlight/cURL/all of them) use RFC 1867 as their design spec, not as some wacky experiment. http://lmgtfy.com/?q=rfc+1867+file+upload+support > No where in the internet standards tracking documents do I see a > definition that restricts multipart/form-data to POST. You're deliberately phrasing it backwards. The documents re: POST enshrine multipart/form-data as one of two encodings. There are no documents re: PUT that refer to form encoding. And I never said there was a restriction; in fact I specifically outlined how 2388 breaks all restrictions on multipart/form-data. However "no restriction" !== "an automatic connection." > I think what you're > referring to is the fact that the client UAs typically only ever handle form > data as multipart/form-data mime as POST-specific requests. This is of > course tied to the fact that client UAs don't typically follow the same > intents of a RESTful API client/server relationship. Allow me to re-iterate > the fact that this is one of the primary focuses of this discussion. That > people normally want to deal with PUT requests in PHP under the umbrella of > building their own RESTful APIs. Show me the RESTful justification for decomposing PUT requests *automatically*. There is none. There may be local knowledge that justifies decomposing PUT requests as if they are POST-like but it is not RESTful. I've read all the REST cookbooks there are. You're trying to make this a thing, and it's not. > It's the same thing as with a POST request today in PHP. Nothing is stopping > anyone from sending a you 2 GB multipart/form-data POST request either. Stop moving the damn goalposts and stay on topic. We are talking about a ***PUT*** today in PHP. Right now, that doesn't cost me anything. In your model it can cost me a lot. We have plenty of ways of warding off oversize requests depending on method. > should be checking intent before dealing with $_POST from the > $_SERVER['REQUEST_METHOD'] anyway, since you can't relay on $_POST > necessarily being indicative of the request method anyway. Certainly with your new feature one would be ill-advised to assume that anything is what it seems. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
