Hi Sara Thank you for your feedback.
On Tue, Jan 23, 2024 at 8:41 PM Sara Golemon <poll...@php.net> wrote: > > On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo <tovilo.il...@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 function `http_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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
