Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
On Wed, 24 Jan 2024 г. at 14:01, Ilija Tovilo wrote: > Hi Sara > > Thank you for your feedback. > > On Tue, Jan 23, 2024 at 8:41 PM Sara Golemon wrote: > > > > On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo > 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[]=2[]=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
Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
Hi Sara Thank you for your feedback. On Tue, Jan 23, 2024 at 8:41 PM Sara Golemon wrote: > > On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo 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
Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo wrote: > I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC. > https://wiki.php.net/rfc/rfc1867-non-post > > Apologies for not seeing the discussion period, but I'll qualify my "No" vote, because I'm actually +1 on the general concept, and this is just a little bikeshedding (this RFC will pass even with a no vote from me). 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`. 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`. -Sara
[PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
Hi everyone I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC. https://wiki.php.net/rfc/rfc1867-non-post Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
