Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78777
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20141106030333.5955732.90669.642@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>
	<20141106030333.5955732.90669.642@gmail.com>
Date: Wed, 5 Nov 2014 22:35:11 -0500
Message-ID: <CAL+t6cEhQDpYh_QgRqWb1RZUJrR-ZsRXxYfyZ7bxrY0C2u-C1Q@mail.gmail.com>
To: Sanford Whiteman <figureonecpr@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bacb5023b147705072862be
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--047d7bacb5023b147705072862be
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 5, 2014 at 10:03 PM, Sanford Whiteman <figureonecpr@gmail.com>
wrote:

> For the umpteenth time, *in what situation must you PUT
> multipart/form-data or multipart/x-www-form-urlencoded only to treat it,
> semantically, as a POST*? Which UA cannot send a POST? It's like we're
> completely upside down on this thread.


> If you're PUTing such POSTful content-types for any reason other than
> storing the entire resource, you're doing HTTP wrong.  Truthfully: if
> someone said, "Yeah, so we got into PUT lately, we use it for Ajax form,
> er, posts, for, um, speed or something," would you not be like, "Wat?"
>


The HTTP specification doesn't restrict how the request body is encoded
based on the request verb. That is up to the content-type and
content-encoding headers. The request verbs themselves are indicative of
intent in the request, not necessarily the composition of said request. So
we're dealing with decomposition not intent. That part is up to the user
not PHP.

multipart form data is useful for including both form data and binary data
with successive parts. Typically the method applied for this mime in the
client UA is POST, but many APIs may apply a PUT request using multipart
form. There's no reason to be restrictive of that in PHP if we doesn't
break compatibility, I don't think.

These are real world problems that people deal with in on the web every day=
.

Here are some sources to demonstrate real world use cases and issues:

- https://github.com/symfony/symfony/issues/9226
- https://www.drupal.org/node/1270190
-
http://uncorkedstudios.com/blog/multipartformdata-file-upload-with-angularj=
s
- https://bugs.php.net/bug.php?id=3D55815

Let's face it. The web is a very imperfect place, but it's very tolerance
to fault is what makes it work so well. Clearly we don't agree with
everything that's done on the web, but that doesn't mean we can't help make
PHP a little more useful on the web.




>
> -- S.=E2=80=8E
>

--047d7bacb5023b147705072862be--