Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122239
MIME-Version: 1.0
References: <CAPyj-LD2W0E+xz0Je5LscQ7d4UONxT2T1eZ0Pw6YjC3wHNbGhg@mail.gmail.com>
 <CAESVnVpMr+TPAwaRve_7sRmeZcLEu37iFH0cgsCQD98DQHxH2w@mail.gmail.com>
In-Reply-To: <CAESVnVpMr+TPAwaRve_7sRmeZcLEu37iFH0cgsCQD98DQHxH2w@mail.gmail.com>
Date: Wed, 24 Jan 2024 12:01:07 +0100
Message-ID: <CAPyj-LC3+8Ok4RFPrqSmeDOE9wmzJ7x37gFc7=iKXz=NuwGS5A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Sara

Thank you for your feedback.

On Tue, Jan 23, 2024 at 8:41=E2=80=AFPM Sara Golemon <pollita@php.net> wrot=
e:
>
> On Mon, Jan 22, 2024 at 1:24=E2=80=AFAM Ilija Tovilo <tovilo.ilija@gmail.=
com> wrote:
>
> > I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC.
> > https://wiki.php.net/rfc/rfc1867-non-post
> >
>
> 1/ This function reaches into the SAPI to pull out the "special" body
> data.  That's great, but what about uses where providing an input string
> makes sense.  For that, and for point 2, I'd suggest
> `http_parse_query(string $query, ?array $options =3D null): array|object`=
.

The RFC previously included support for the $input_stream variable
(string is not very appropriate for multipart because the input may be
arbitrarily large). The implementation wasn't complex, but it required
duplication of all the reads to support both a direct read from the
SAPI and a read from the stream, duplication of some limit checks and
special passing of the streams to avoid SAPI API breakage.

As for actual use cases, I found limited evidence that this function
would be useful for worker-based services _right now_. Most services
handle request parsing in some other layer. For example, RoadRunner
has a Go server that stores the file to disk, and then just passes the
appropriate path to PHP in the $_FILES array. It seems to me that a
custom input would be useful exclusively for a web server written in
PHP. The one that was pointed out to me (AdapterMan) handles requests
as strings, which would not scale for multipart requests.

I don't mind getting back to this if AdapterMan rewrites request
handling to use streams. Adding back the $input_stream parameter can
be done with no BC breaks. But for the time being, I don't think the
motivation is big enough to justify the added complexity.

Additionally, because multipart is used exclusively as a request
content type, it isn't useful in a general sense either, because a PHP
request will typically only receive one request (but potentially
multiple responses, in case it communicates with other servers).

> 2/ `request_` represents a new psuedo-namespace, functions are easier to
> find and associate if we keep them grouped.  I recommend 'http_` because =
it
> compliments the very related function `http_build_query()`, and for the
> version of this function which refers directly to the request:
> `http_parse_request(?array $options =3D null) : array|object`.

That's fair. If the name bothers you I can create an amendment RFC. I
think http_parse_body() would be a bit more appropriate, because
request implies more than just the body.

Ilija