Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78798
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAA8DMBvwf_8EOD7cFYbBggAQqEUy_rR6uYApd7Sse4f-ArNUOQ@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>
	<CAA8DMBvwf_8EOD7cFYbBggAQqEUy_rR6uYApd7Sse4f-ArNUOQ@mail.gmail.com>
Date: Thu, 6 Nov 2014 03:56:27 -0500
Message-ID: <CAL+t6cEVQaivZXENJuE7+BjgqPU0j4m4k-WJVzF=Xsbp4amciw@mail.gmail.com>
To: Sanford Whiteman <figureonecpr@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: multipart/alternative; boundary=f46d04138ae32500ff05072cdf38
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--f46d04138ae32500ff05072cdf38
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 6, 2014 at 3:20 AM, Sanford Whiteman <figureonecpr@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.
>

--f46d04138ae32500ff05072cdf38--