Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78761 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31077 invoked from network); 6 Nov 2014 00:31:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Nov 2014 00:31:30 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.208 imap2-3.ox.privateemail.com Received: from [192.64.116.208] ([192.64.116.208:58582] helo=imap2-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A6/60-28384-C51CA545 for ; Wed, 05 Nov 2014 19:31:24 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 75E078C0080; Wed, 5 Nov 2014 19:31:21 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at imap2.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap2.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SVS1J_nJ-mM0; Wed, 5 Nov 2014 19:31:21 -0500 (EST) Received: from oa-res-26-28.wireless.abdn.ac.uk (oa-res-26-28.wireless.abdn.ac.uk [137.50.26.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 8E4EA8C007B; Wed, 5 Nov 2014 19:31:20 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) In-Reply-To: Date: Thu, 6 Nov 2014 00:31:18 +0000 Cc: Patrick ALLAERT , PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me> References: To: Sherif Ramadan X-Mailer: Apple Mail (2.1990.1) Subject: Re: [PHP-DEV] New Standardized HTTP Interface From: ajf@ajf.me (Andrea Faulds) > On 5 Nov 2014, at 22:29, Sherif Ramadan = wrote: >=20 > =46rom all the people I've spoken with that have a problem with = handling PUT > requests in PHP, it seems that they'd rather have PHP populate > $_FILES/$_POST automatically in this case. Which would be relatively = easy > to do by modifying the default post reader function in the SAPI > http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however, = that > is itself a small BC break. >=20 > Does anyone have any recommendations on what they think the best = approach > is? I'd appreciate any feedback/suggestions/constructive-criticism. = Thanks! I don=E2=80=99t think auto-populating for PUT/DELETE etc. is a good = idea, they=E2=80=99re quite different semantically. If I send a DELETE = request to code expecting a POST, and PHP pretends it=E2=80=99s a POST = request, that=E2=80=99s bad. However, I think the solution is simple: Add a function to do = multipart/form-data parsing. Not a suite of functions, not a class, just = one simple function. That way, for the few people that need it, they can = do $_POST =3D = multipart_form_data_parse(file_get_contents(=E2=80=98php://input')); and = their problem=E2=80=99s solved. If we can=E2=80=99t expose the parser, we could also just add a function = to force population (force_parse_post_data() or something?). Again, this = allows the few that need this to do so explicitly, but doesn=E2=80=99t = make $_POST allow it for everyone else. -- Andrea Faulds http://ajf.me/