Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78793
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cGmEonNk0=Dkmih2G96WrXFDrcsn376eN0RjuuWWGPv4g@mail.gmail.com>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com>
	<CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com>
	<1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
	<CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com>
	<468730E8-4C38-49A3-A61A-59E107313D79@ajf.me>
	<CAL+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com>
	<CC2E198C-1B05-4329-B13D-47787EBE9FFC@php.net>
	<CAL+t6cESCv6s2AHGubuJ+vK26wpq0Uzn39JBLy+vZD8SNskqXw@mail.gmail.com>
	<9FB8B541-A040-4C0E-8884-A1EA06B3C266@php.net>
	<CAL+t6cGmEonNk0=Dkmih2G96WrXFDrcsn376eN0RjuuWWGPv4g@mail.gmail.com>
Date: Thu, 6 Nov 2014 03:20:53 -0500
Message-ID: <CAA8DMBvwf_8EOD7cFYbBggAQqEUy_rR6uYApd7Sse4f-ArNUOQ@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: Will Fitch <willfitch@php.net>, Andrea Faulds <ajf@ajf.me>, 
	Patrick ALLAERT <patrickallaert@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: figureonecpr@gmail.com (Sanford Whiteman)

> 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.