# [RFC][Vote] RFC1867 for non-POST HTTP verbs

- Thread: https://externals.io/message/122213
- Original archive: https://news-web.php.net/php.internals/122213
- Started by Ilija Tovilo on 2024-01-22T09:23:50+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #122213 — Ilija Tovilo — 2024-01-22T09:23:50+00:00

URL: https://externals.io/message/122213#122213

Hi everyone

I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC.
https://wiki.php.net/rfc/rfc1867-non-post

Ilija

---

## #122236 — Sara Golemon — 2024-01-23T19:41:04+00:00

URL: https://externals.io/message/122213#122236 · In reply to: #122213

> 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

---

## #122239 — Ilija Tovilo — 2024-01-24T11:01:07+00:00

URL: https://externals.io/message/122213#122239 · In reply to: #122236

Hi Sara

Thank you for your feedback.


>
> 
>
> > […]
>
> 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

---

## #122281 — Ilija Tovilo — 2024-02-05T10:23:58+00:00

URL: https://externals.io/message/122213#122281 · In reply to: #122213

Hi everyone


>
> I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC.
> https://wiki.php.net/rfc/rfc1867-non-post

The RFC has been accepted with 23 yes and 1 no vote. As promised to
Sara, I will be setting up a poll for the suggested, alternative
function name in the coming days.

Ilija

---

## #124281 — Valentin Udaltsov — 2024-07-08T08:45:37+00:00

URL: https://externals.io/message/122213#124281 · In reply to: #122239

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

> Hi Sara
>
> Thank you for your feedback.
>
> 
> > […]
> wrote:
> > […]
>
> 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).
>
> > […]
> it
> > […]
>
> 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