Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108746 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 17340 invoked from network); 24 Feb 2020 23:30:25 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Feb 2020 23:30:25 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 43330180089 for ; Mon, 24 Feb 2020 13:47:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 24 Feb 2020 13:47:37 -0800 (PST) Received: by mail-wr1-f41.google.com with SMTP id g4so5877130wro.13 for ; Mon, 24 Feb 2020 13:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=d23SsklJn0geSlza29UdWgIWhau1ATLWFE1cQAvwvaA=; b=Q+UvMJ0gj5CsVZ0q6mghHrRAimCFnv5zGalsnvsY1R+ymn9x5jQpr2T/PEk52qOyP4 GqcLL284UfsrcBkvz/Onl7EQkT5hIoCWMwBXeyvz/E8mHmElWk3LMxs0FwLj5mxjt8NE lchvFuNKPP5DDRpLM9Qh7ZTEmBCk+sgr9iE4bYZ0YFnJKs7z9TZBcWrCbx0lPuOfMnhk n2Pq6m3mV2W0KCyk8o88Sw6TBq+f5zU23qjHo7w/l0ntsEHDiJeZTagzoupGDOoafvwA dgvC3n/G7L0lgU9T2p01ljyoD7NchVHcRaVWAElrQAXbyDaj0QxUkBV9scye02QtNu0c GIAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=d23SsklJn0geSlza29UdWgIWhau1ATLWFE1cQAvwvaA=; b=AnSej+z7wQNYqjHHYQV1eEaVPegAryeEr8+SvJD7qqkq6mpkUaHeow1MNKKERWpmA3 AQMJoofcnlk9eFJDfW50uvCW8epTg9rtxOT+Q7Tpe61Gn3UO7HgoMoxPKLHqQVq7lHeJ Iqa7rPZE+gEp17uQbr0D57W8L3MLk9e08Nma1QBeJ4PxSPAQDYSk/CTvyoWET6Fwg/Vl nDyciD2Guo/+Hf67hGj7T5/1HXiz7c82x4GI2uDUbqgViZSuG/fbOEfJ3a4Kx4k1/aOO QS9No2Dy9WXRGt3av/PuKKNztCWtQ8+alfsxKfWnfG9jECEtx4Zjp8PqcaOPLUOKgiHM 0D/Q== X-Gm-Message-State: APjAAAVCBDcFjMJWeHugskz2YkCaOhswLJU85+17AsoAAukij9Hg9RhN 6yljUfe50fOhZ0zy38WV+7lpIYTh X-Google-Smtp-Source: APXvYqz2iSNn5W+mSp/pQsYVC3rJBZ04z9Sl25SYFrUU9rrBVGB8OYVpAfg3giTqWRy+9uIFi+GfoA== X-Received: by 2002:a5d:6087:: with SMTP id w7mr67225609wrt.36.1582580855630; Mon, 24 Feb 2020 13:47:35 -0800 (PST) Received: from [192.168.0.14] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id t13sm20300775wrw.19.2020.02.24.13.47.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2020 13:47:35 -0800 (PST) To: php internals References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <5904137.fSVIMsojiJ@mcmic-probook> <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io> <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com> <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io> <1BF3D29A-04C6-4A82-9216-EAE991A38916@pmjones.io> <10388b3a-3402-a6dc-3837-b03d735edf46@gmail.com> Message-ID: <5ec7b4a7-508b-270b-916f-0504a116196c@gmail.com> Date: Mon, 24 Feb 2020 21:47:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: rowan.collins@gmail.com (Rowan Tommins) Hi Paul, I left this thread to settle a bit, because I felt we were going round in circles a bit. I think there's some fundamental differences in outlook that no amount of discussion is going to resolve, so I've trimmed this reply to the more specific points. On 20/02/2020 14:56, Paul M. Jones wrote: > Aha! If nothing else, then, this conversation has revealed a > documentation flaw: specifically, my failure to document the > ServerRequest $url property. That failure is now remedied: > Aha indeed! When I was talking about "selling it to me", this is exactly the kind of thing I was looking for. This kind of functionality is much more interesting to me than copying half a dozen arrays from constructor parameters into read-only properties. > Which is the purpose of the documentation; it describes the differences between $files and $uploads. That's no reason not to *try* for descriptive names, though. I presume the idea is that one array is expected to be more useful for new code, and the other is mostly there for compatibility with old code? If so, perhaps the names could reflect that somehow. Incidentally, the current documentation doesn't describe the differences particularly well, just saying one is "more like $_POST". Some details of the structure, or examples comparing the two arrays, would be useful. >> I was actually thinking of the opposite: given a request body which didn't come from global state, but which contains data in multipart/form-data format, extract the key-value pairs and attached files. > Is that something PHP "itself" already does? If not, I have to consider it out-of-scope for this RFC. a) Yes: Every time you submit a form as multipart/form-data, PHP parses it into the global state. If this object is aiming to abstract away from global state, then having a non-global-state parser for that seems consistent. b) No: There is no function which currently takes a string and returns an array for this scenario. However, that's true of other features you have included, such as parsing accept headers, or even extracting just HTTP headers from a copy of the $_SERVER array. > Your point on global state is well-taken; I will try to remember in future to phrase it as "global *mutable* state." (AFAICT, php://input is not mutable, though as you correctly point out, it is global.) This distinction seems unnecessary. Once created, the object avoids global state because it is self-contained, and the fact that it's read-only is a separate attribute. We're really just talking about ways to construct that self-contained state, and "everything from global state" or "nothing from global state" seem like more natural options than "one thing from global state, everything else not". Regards, -- Rowan Tommins (né Collins) [IMSoP]