Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88198 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77923 invoked from network); 14 Sep 2015 21:56:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Sep 2015 21:56:16 -0000 Authentication-Results: pb1.pair.com smtp.mail=mailto.woden@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mailto.woden@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender) X-PHP-List-Original-Sender: mailto.woden@gmail.com X-Host-Fingerprint: 209.85.217.172 mail-lb0-f172.google.com Received: from [209.85.217.172] ([209.85.217.172:35191] helo=mail-lb0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9F/15-48700-E7247F55 for ; Mon, 14 Sep 2015 17:56:14 -0400 Received: by lbpo4 with SMTP id o4so75039642lbp.2 for ; Mon, 14 Sep 2015 14:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=t0yQ0f2f0A6DRssl9Imcv4c1etcfP9YVBW3yXQ++9W8=; b=rm1lDyXstAdpknuB/ugz2JpQiXkN/mMX6327DW/HM/yqxj9X2jOrbl0LuRWl8ORGgt 7Ig8ZkV1wtLF9BrrWJa9/iZgUdpEfsu1MNNqPmP0JV7ta8/SMcsCPVVjsirogksziMXA DscG42cWm97c3hZPU7e42tic9R9MJsW85yxcg+CKGt2XlDxWGmIA4qltRMjtoAt+kHfU +sL4zxqeyolg7DYnYuy6neHZ9CMYwjGym+n06A0leelNBGI1+djyJ6yy6sS4udWWZuB5 L1mSI+IM5jSmH8mn0H3d9udenIEqU42fGyCmCTK9+KxYqfcMhcN5rJ02nUPM57JR/aEe 3tnA== MIME-Version: 1.0 X-Received: by 10.112.159.72 with SMTP id xa8mr3383794lbb.118.1442267771299; Mon, 14 Sep 2015 14:56:11 -0700 (PDT) Received: by 10.114.78.231 with HTTP; Mon, 14 Sep 2015 14:56:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 14 Sep 2015 23:56:11 +0200 Message-ID: To: PHP Internals Content-Type: multipart/alternative; boundary=001a11c285ca2deb51051fbc2255 Subject: Re: [PHP-DEV] Suggestion: Adding PUT, PATCH and DELETE From: mailto.woden@gmail.com (Daniel Persson) --001a11c285ca2deb51051fbc2255 Content-Type: text/plain; charset=UTF-8 I've read some of the earlier discussion (not all, require sleep will read more tomorrow). To be clear I don't want to start a naming discussion again. If we have a new name for $_POST or not isn't the main focus of this PR. I want to allow PUT, PATCH and DELETE and handle them the same way as POST so we get populated globals with data we could later filter and use. Most of the frameworks work around this limitation in the core so I thought it might be in place to suggest we allow these request methods. On Mon, Sep 14, 2015 at 11:38 PM, Ryan Pallas wrote: > > > On Mon, Sep 14, 2015 at 3:22 PM, Daniel Persson > wrote: > >> Hi. >> >> I've not been a member for too long so I might have missed if this have >> been discussed earlier. >> >> But I've created a small PR to the basic request handling to support PUT, >> PATCH and DELETE. >> >> https://github.com/php/php-src/pull/1519 >> >> Summary: >> >> Added support for request methods with the smallest change possible. >> History: >> >> HTTP 1.0 had only support for GET, POST and HEAD. >> In June of 1999 HTTP 1.1 added the verbs PUT and DELETE and later in 2010 >> RFC5789 (https://tools.ietf.org/html/rfc5789) added PATCH. >> Pull request explaination: >> >> In this pull request I try to add put, patch and delete with changing as >> few functions as possible. I simply handle the new verbs as POST. As >> defined in HTTP 1.1 they are similar in input data requirements and differ >> only in usage. >> > > +1 from me, would love to see the verbs supported more fully. (though my > approval means quite literally nothing). How does this affect something > like the ini settings for variable order? IE. does GPC change from GET -> > POST -> COOKIE to GET -> PARSED_INPUT -> COOKIE? Since only a single verb > is available for any single request, this makes the most sense for me. > > >> >> More work I could do is add new globals for $_PUT, $_PATCH and $_DELETE >> but >> I think this might be more confusing. Or we could move from $_POST to a >> new >> global not tied to a verb. Example $_PARSED_INPUT > > > As for having a new $_PARSED_INPUT, I'm not sure I like this for 2 reasons > a) the name is 2 words, all other super globals are single words (unless > there's one I do not know of) and b) It feels like too long a name, sure in > an IDE it will auto-complete for us, but for quick edits in vim for > example, this name would suck. But my only problem with it is on a name > level, about about just $_INPUT or does this seem to conflict with > $_REQUEST which holds multiple super globals worth of data already. > --001a11c285ca2deb51051fbc2255--