On Wed, 24 Jan 2024 г. at 14:01, Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> 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 > > 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
