Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78008 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89954 invoked from network); 14 Oct 2014 14:09:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Oct 2014 14:09:01 -0000 Authentication-Results: pb1.pair.com header.from=are.you.winning@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=are.you.winning@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.176 as permitted sender) X-PHP-List-Original-Sender: are.you.winning@gmail.com X-Host-Fingerprint: 209.85.216.176 mail-qc0-f176.google.com Received: from [209.85.216.176] ([209.85.216.176:47888] helo=mail-qc0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EC/41-18603-B7E2D345 for ; Tue, 14 Oct 2014 10:08:59 -0400 Received: by mail-qc0-f176.google.com with SMTP id r5so6634462qcx.7 for ; Tue, 14 Oct 2014 07:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kXYBjBJwmOw1R6UmtH70lz4mH+cARWjHJgRynmc+ZYo=; b=UW54s+Q3isN+9B1Dwt4xciABsDo+vJCIf2cs3wk8WesWXLcBk0Zdh88k33xOVZGQr3 BMcr0MnDkWJWAib02qlQ6EGeGk+IQo3aCbnhobmC9aSft/8vz52kgzy2UuXAMFDhO8ti 5b8GDBXul1tcJCuYgNLyLM2CFsN+7Fi3SEqXzX+IO5euF/5cHchqPQuzV+s9DI/jXcuC X70r16n98ImpCaC+OtRGiR4EOJWZ5GEYPFem7KjtaXrF8q4DXnaw35dl7t9yHeuW7WBL om+7ntygifV8DD3OxE4hpptap1WOONVyNNLt0sCHjkxuwtjtCWZq04RkGyY01TWnLruL rLYA== MIME-Version: 1.0 X-Received: by 10.224.64.71 with SMTP id d7mr9722560qai.16.1413295735891; Tue, 14 Oct 2014 07:08:55 -0700 (PDT) Sender: are.you.winning@gmail.com Received: by 10.141.28.193 with HTTP; Tue, 14 Oct 2014 07:08:55 -0700 (PDT) In-Reply-To: References: <776669CE-9E8C-4069-9834-C7275CCA0EF4@ajf.me> <8CB055D4-F164-4DF3-B019-684BAE7E016E@ajf.me> Date: Tue, 14 Oct 2014 15:08:55 +0100 X-Google-Sender-Auth: TDyPU-8TqlGu6Eu3gKVqaSP1Log Message-ID: To: Kris Craig Cc: Chris Wright , Mike Dugan , Andrea Faulds , Kristopher , PHP internals list , Andrey Andreev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] New globals for PUT and DELETE From: cw@daverandom.com (Chris Wright) On 14 October 2014 14:57, Kris Craig wrote: > On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright wrote: > >> On 14 October 2014 14:46, Kris Craig wrote: >> > On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan wrote: >> > >> >> >> >> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (ajf@ajf.me) wrote: >> >> >> >> >> >> On 14 Oct 2014, at 14:27, Kristopher >> wrote: >> >> >> >> > $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. >> >> >> >> Ew, non-superglobals. >> >> >> >> But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QU= ERY >> >> (for $_GET) and $_BODY (for $_POST)? Then the variable set finally ma= kes >> >> sense, but isn=E2=80=99t too long: >> >> >> >> * $_QUERY - query string parameters >> >> * $_BODY - request body parameters >> >> * $_REQUEST - query string and request body parameters >> >> >> >> Makes more sense than $_GET and $_POST. >> >> >> >> Any objections? >> >> >> >> -- >> >> Andrea Faulds >> >> http://ajf.me/ >> >> >> >> >> >> +1 for this. This would hopefully also eliminate the confusion for ne= w >> >> developers (or not-so-new developers) who don=E2=80=99t quite underst= and that >> $_GET >> >> and $_POST don=E2=80=99t strictly relate to their HTTP verbs of the s= ame name. >> >> >> >> -- >> >> >> >> Mike Dugan >> >> >> >> mike@mjdugan.com >> >> >> > >> > That could work, though the BC breakage will be extreme. I'm not sure= if >> > that's worth it even in a major version increment. On the other hand, >> > making $_PUT and $_DELETE available wouldn't break anything and wouldn= 't >> > require re-training for devs. >> >> ...but is also the wrong solution. It's not scalable, > > > How is it not scalable, exactly? It's just a couple aliases. Because in a few years when the FOO request method has become commonplace we will get requests to add support for $_FOO, and then $_BAR, and the $_CHEESE... where does it end? > >> and the only >> sensible way to implement them would be as aliases of $_POST, because >> they would contain the same data. How does this fundamentally differ >> from $_BODY (or whatever)? >> > > It's not supposed to functionally differ. It's supposed to create some > better consistency and make it easier for devs to differentiate between > different REST methods when retrieving data. If REQUEST_METHOD is PUT, > then I can set the parsed params to the value of $_PUT. The aliases matc= h > the methods used, making the code that much more readable and scalable. This doesn't actually help anything, though, if anything it hinders it. You route your request based on the method, this way you would either have to couple the first layer after routing to the method by using a specific named superglobal at that layer, or have a switch/case, variable variable or some other nastiness at the top level to pick the right superglobal to the next layer. If the form data submitted by the request entity body - always in the same place in every HTTP request message - is always in the same data store at the PHP layer, there's an extra decision taken away. > --Kris To be brutally honest I see this as a discussion of highly questionable merit anyway, due to the fact that in the overwhelming majority of cases where the request method is not POST the entity body will not represent HTML form data - browsers don't make requests of these methods with the involvement of client-side scripting at the moment (or in the foreseeable future), the content type of the request body is *highly* unlikely to be something PHP would even attempt to decode. Sorry.