On Thu, Nov 6, 2014 at 3:20 AM, Sanford Whiteman <figureone...@gmail.com> wrote:
> > Nowhere did I suggest that the request verbs themselves (i.e. PUT and > POST) have the same intent. Just > > that the handling of multipart-form data is not specific to either one of > > those verbs. > > Define "handling." :/ > 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. > > "Handling" as in "interpreting multipart/form-data as key-value > pairs": a specific, intimate relationship with POST exists in RFC 1867 > First of all, RFC 1867 is not a standard. It's an experimental protocol definition. No where in the internet standards tracking documents do I see a definition that restricts multipart/form-data to POST. 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. > > > I see no reason why this would be a negative impact on PHP. > > Because if someone PUTs 2 GB of multipart/form-data I don't want it > decoded just because somewhere in my code path there's a reference to > $_POST. > > 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. You should be checking intent before dealing with $_POST from the $_SERVER['REQUEST_METHOD'] anyway, since you can't realy on $_POST necessarily being indicative of the request method anyway. > -- S. >
