Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78368
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.194 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPRqa+HF1JqG5dCU3XQtzTRvUHhC_44M8QeXH1NQ+pGWaCKQFA@mail.gmail.com>
References: <CAKOpQSwS=Xck41sQQyEYGG8L3VHq+fRWjy0dDorbwZaVWMLCow@mail.gmail.com>
	<776669CE-9E8C-4069-9834-C7275CCA0EF4@ajf.me>
	<CAKOpQSwRtSU1LNmftyY1b09SONBCfwS-qiMK4gct6uFiW3CSjw@mail.gmail.com>
	<CAPhkiZwb13FmX+sQLx0Ki52KuwJ4HWTj-84UqcZq3GYPFL8Tnw@mail.gmail.com>
	<E8F7D721-767C-4E6E-B0BB-F0DEFEB308B2@ajf.me>
	<CAF9U7z_0cgwWFEoShU9rJhoOZttztcZk_NAqoXnSuAro-w3kew@mail.gmail.com>
	<8CB055D4-F164-4DF3-B019-684BAE7E016E@ajf.me>
	<543D47C1.9050009@lerdorf.com>
	<etPan.543d4c0e.216231b.12d@Mikes-iMac.local>
	<543D4CE1.5000109@lerdorf.com>
	<543D6864.10508@gmail.com>
	<543D85E6.2020507@lerdorf.com>
	<CAKOpQSyTSZeXppZ-f9OeNfA9=Q58jte1fH6zcuzxYZ+qK7-6JA@mail.gmail.com>
	<57b7a3681d6c2c7ae123c8921b2d19d6@mail.gmail.com>
	<CAHsEcH_m3MHq2qTa=zrtZs9Ub1SoimeHJ1A9s9Efwdu6U9APJw@mail.gmail.com>
	<544D65F7.8070807@sugarcrm.com>
	<CABRjmp-6TsMHgzM8_A9M5mUD=ModTH4H3g-Vf-59_4kXtKo+cA@mail.gmail.com>
	<CAPRqa+HF1JqG5dCU3XQtzTRvUHhC_44M8QeXH1NQ+pGWaCKQFA@mail.gmail.com>
Date: Mon, 27 Oct 2014 01:09:25 -0400
Message-ID: <CAA8DMBtfTrCjfFjg=16a7C_SaA33nMza5EeRcv=z1-TGObGT0A@mail.gmail.com>
To: Park Framework <park.framework@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: figureonecpr@gmail.com (Sanford Whiteman)

> PUT, DELETE, must be available in a single global variable, the
> variable name is not important
> file_get_contents(=E2=80=98php://input') - uncomfortably

If the quibble were with file_get_contents(=E2=80=98php://input') that's no=
t
sufficiently uncomfortable to warrant a new superglobal. I assume you
mean parsing the contents of php://input into an associative array
regardless of the content-type of the HTTP entity-body.  However,
you're glossing over the semantic difference between POSTing an
entity-body and PUTing that same body.

multipart/form-data is specified in RFC 1867 as POST-specific, with
deliberate notes about expected server behavior.  RFC 2388 expands
form-data into a general mimetype regardless of transport, and
theoretically regardless of HTTP method, but AFAIK there's no
equivalent to 1867 that reasonably leads to auto-decoding PUT
form-data into an associative array. Rather, the PUT payload has
always been designed to _become_ the target resource, as-is.  The POST
payload is designed to be interpreted via the server's own semantics
before changing any resource state. Thus there is a very strong reason
to present POST data to the server in an easily accessible and mutable
form.  Not so for PUT.

This doesn't mean PUT payloads must stay opaque to PHP, of course.  If
there's a need to validate the payload before overwriting the current
resource state, that may require that it be passed through some binary
image verification, validated against a DTD, or -- indeed -- decoded
from multipart MIME into its parts for validation, even if it's the
multipart representation that eventually gets stored.  Yet if you feel
that PUT content should be automatically decoded, you might as well
apply this to other multipart content as well -- if I PUT an MHTML
file or, as noted before, an RFC 822 e-mail, by this assumption those
would also populate the new superglobal.  Honestly if it didn't
consume any extra resources to always populate, I wouldn't care.   But
to be unable to avoid decoding every giant multipart payload just
because I _might_ want to look at the parts is highly inefficient.

-- S.