Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cGiAPeGy=8QaW59+xBydRf8xbPcRAK=8V3ocuArsf6wyw@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>
	<20141106030333.5955732.90669.642@gmail.com>
	<CAL+t6cEhQDpYh_QgRqWb1RZUJrR-ZsRXxYfyZ7bxrY0C2u-C1Q@mail.gmail.com>
	<CAA8DMBvAKxq9Dtz3VfgT8AOxGfpE6zrtCcKp4nAwuJK39kCz7w@mail.gmail.com>
	<CAL+t6cGiAPeGy=8QaW59+xBydRf8xbPcRAK=8V3ocuArsf6wyw@mail.gmail.com>
Date: Thu, 6 Nov 2014 04:56:14 -0500
Message-ID: <CAA8DMBs7BsABFkVC3RojzKobj36viwhfPLhP3QFvK6DWEvskZw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: figureonecpr@gmail.com (Sanford Whiteman)

> PUT is not intended to necessarily store the request entity body on the f=
ile
> system. Its intention is to store the entity body at the request URI.

I never said it was.  I used the expression "store at the URI" about
10 ten times on this topic.  You are arguing in bad faith by putting
words in my mouth.  Stop.

In a barebones implementation with just an HTTPd, PUT does mean the
filesystem, which gives an easy example of how incredibly semantically
different it is from POST. Most people do not understand the concept
unless you give them a simple example.

> So this unfounded claim that decomposition should not happen within PHP a=
t the request level, isn't a justification for prohibiting PHP from decompo=
sing the body.

I made no such claim.  I maintain that decomposition not be *required
to happen* within PHP.  I couldn't care less if you make it optional
and don't use the $_POST superglobal. I've said this over and over.
Expose the core MIME parser to the user.  That'll make it easily used
by frameworks, or via auto_prepend_file.  Do not do it automatically
for all requests.

> For example, if the Content-type designated in the request indicates appl=
ication/binary it is safe to say that PHP should not attempt to disassemble=
 the input stream beyond applying > the decoding from the Content-encoding =
header (which may actually happen at the web server level). However, in thi=
s event it would make it a lot more convenient for the client if the > enti=
ty is stored in $_FILES where its access is still more manageable through t=
he receiving code.

I noted this case in the other thread and let it be laughed off, but I
actually believe that this is a relatively sensible option, since it
doesn't require any decoding.  For that matter, I
ninety-percent-kiddingly wondered if an application/tar body could be
decomposed and its constituent files put into $_FILES, since that's a
case we actually use daily. Again under user control, and not for
every request to a given PHP install, but a kind of pre-superglobal
API would be cool.  Of course I know it'll never happen and I'm fine
with that.