> 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." :/ "Handling" as in "interpreting multipart/form-data as key-value pairs": a specific, intimate relationship with POST exists in RFC 1867 and in the HTML4 and 5 specs. These documents show the relationship between POST and multipart/form-data to be a very special one, one in which the innards of a form-data entity-body are meant to be expanded at runtime to replay the individual fields of an originating form. There is no such document that relates to PUT. "Handling" as in "accepting data that happens to be multipart/form-data": of course that's not method-specific. It's not even HTTP-specific anymore. As of RFC 2388, form-data can be sent from Adobe Acrobat over IPX/SPX to an AS/400. That's great, it's a real standard. MIME decoders/encoders will grok it as a specialization of multipart MIME, and apps can apply stricter validation than for multipart/mixed (for example, mandatory part names). The expanded standard also means that intermediate systems may be designed to *transport* or *save* multipart/form-data messages instead of *reading* them. Which brings us back to the point: hands off PUT entities, unless there's overriding local knowledge that they must be read instead of stored. > 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. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
