[RFC][Vote] RFC1867 for non-POST HTTP verbs View as Markdown

On Wed, 24 Jan 2024 г. at 14:01, Ilija Tovilo tovilo.ilija@gmail.com
wrote:

Hi Sara

Thank you for your feedback.

On Mon, Jan 22, 2024 at 1:24 AM 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 = 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 functionhttp_build_query(), and for the version of this function which refers directly to the request: http_parse_request(?array $options = 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

--

To unsubscribe, visit: https://www.php.net/unsub.php

Hi, Ilija!

I think that removing $input_stream should be revisited.
The problem with Go/RoadRunner/PHP is that PHP parses a[]=1&a[]=2&a[]=3
differently from other languages.

PHP: [a => [1,2,3]]
GO: map[a[]:[1 2 3]]

See https://github.com/roadrunner-server/roadrunner/issues/1696 and
https://github.com/roadrunner-server/roadrunner/issues/1963#issuecomment-2209403600
for more details.

To mitigate this issue, RoadRunner allows raw body on the PHP side
by setting http.raw_body = true. Here's where request_parse_body would be
useful if it accepts other streams.

Best regards,
Valentin