Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108774
MIME-Version: 1.0
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <CANUQDCiP31aEqULqeGpN66ESHarKxWuXgQt_CqWeCLZc+1L-fA@mail.gmail.com>
 <5904137.fSVIMsojiJ@mcmic-probook> <CDBA02D0-07E1-4723-947C-22B403E650C0@pmjones.io>
 <CA+hqhpcOqCqXuOh3bWavJ+pZ5VVhekUO9LkKgd9c+b98VVnZSA@mail.gmail.com>
 <CAG9XoMRm2Nqjg3UbCc5=1_8m2W7qf8QRoSVk6d_qENJCKE1=9A@mail.gmail.com>
 <fcf43463-f9f7-4235-a84b-658074772ed7@www.fastmail.com> <3DDBFBA4-8D3A-46C5-9A10-B093A5E2386B@pmjones.io>
 <54493258-B52E-442A-A11D-82E1D4C7DE5E@gmail.com> <8264F6CF-AD55-41E2-9F5A-DAE8942E2B79@pmjones.io>
 <f58eea0a-6d71-be57-c0b8-abc4321cdb38@gmail.com> <1BF3D29A-04C6-4A82-9216-EAE991A38916@pmjones.io>
 <10388b3a-3402-a6dc-3837-b03d735edf46@gmail.com> <CE336F26-F119-49E6-BD7E-43B47B7F4463@pmjones.io>
 <5ec7b4a7-508b-270b-916f-0504a116196c@gmail.com> <30112AFF-38F9-44D4-9D2F-03A32019764F@pmjones.io>
In-Reply-To: <30112AFF-38F9-44D4-9D2F-03A32019764F@pmjones.io>
Date: Wed, 26 Feb 2020 18:55:20 +0000
Message-ID: <CALKiJKqenOLuUFECKVNPu3ng70q+PGroocWZ7wN1z555Cq-3Mg@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000e1595059f7f26ec"
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000000e1595059f7f26ec
Content-Type: text/plain; charset="UTF-8"

On Wed, 26 Feb 2020 at 16:42, Paul M. Jones <pmjones@pmjones.io> wrote:

> Your presumption is correct! And your point on trying for better names is
> well-taken -- though I think these are "expected" names, based on my
> research into existing implementations. The most-common names are ...
>
> - the word "files" for unparsed or unmodified $_FILES values, leading me
> to think $files is well-understood
>
> - the words "upload(s)", "fileUpload(s)", or "uploadedFile(s)" for parsed,
> transformed, or restructured $_FILES values, leading me to think $uploads
> is well-understood
>


That's a reasonable justification. Just to check, are there other
implementations that have both of these names side by side, or do most
implementations have one or the other, but using this naming?

The main confusion I can see is having to remember which two of these is an
error without having to read the docs each time:

isset( $request->files['attachment']['name'][0] );
isset( $request->files['attachment'][0]['name'] );
isset( $request->uploads['attachment']['name'][0] );
isset( $request->uploads['attachment'][0]['name'] );




> Having said that, I am open to suggestion here. What names do you think
> would be better than the ones presented, contra pre-existing work from
> other authors?
>


Looking at the examples, the difference is rather similar to the
PREG_PATTERN_ORDER and PREG_SET_ORDER options to preg_match_all.

If getUploads was a method, it could take a similar behaviour switch -
GROUP_BY_ITEM vs GROUP_BY_ATTRIBUTE or similar. For a property, that would
have to be part of the name, like $uploadsByItem and $uploadsByAttribute,
which are a bit ugly.

Alternatively, you could lean more heavily on the legacy aspect, and have
$uploads and $uploadsLegacyFormat or something like that.



> 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.
>
> Good call! On your suggestion, I have added details at <
> https://github.com/pmjones/ext-request#the-uploads-array>.  Suggestions
> for improvement are welcome.
>


Thanks, that makes it a lot clearer. :)




> - "There is no function which currently takes a string and returns an
> array for this scenario." -- True, though (and not to undermine my own
> case) there is json_decode(), which can return an array. But then the
> trouble is how to decide when to apply it, and with what parameters, and
> how to trap & report errors, etc., all of which adds complexity to what I
> think ought to be a simple object. And then once special treatment is given
> to JSON, what about XML? Etc., etc. Given all that, it strikes me that the
> cases not already served by PHP for parsing the body content into $_POST
> are best left to consumers of ServerRequest.
>


Again, any mention of JSON or XML is drifting away from what I'm asking
for. What I'm asking for (or rather, suggesting would be a useful and
consistent addition) is a way to do *exactly what PHP does right now*, but
based on a given input string, rather than the initial request. I am
totally happy with users needing to add any support for JSON, XML, etc,
just like they would have to populate $_POST manually.




> I agree that the default $content value is an exception to everything else
> in ServerRequest. While it stays read-only, it does get read from
> php://input each time you refer to it.
>
> The alternative is to read from php://input once at construction time
> (when the construct $content argument is null) and retain that value in
> $content from the start. But in that case, when you have very large content
> bodies (as when there are PUT file uploads or other large payloads), then
> ServerRequest takes up a lot of memory, when it might not ever be used
> directly. Yes, "it might never be used" could be true of every element on
> ServerRequest, but the maximum memory use for those other elements tends to
> be rather smaller.
>


That's a reasonable justification. I guess that's why PSR-7 exposes it as a
stream, even though that causes a whole load of pain.

To play devil's advocate, does the property belong in the object at all? If
it doesn't interact with any of the other properties (e.g. populating $post
and $uploads based on form data), could "better syntax for getting raw
request for global state" be a separate feature. Then again, maybe the
ability to over-ride it in the constructor is enough to make it useful.


Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000000e1595059f7f26ec--