Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
| From: | Ilija Tovilo | Date: | Wed, 17 Jan 2024 12:55:19 +0000 |
| Subject: | Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122168@lists.php.net to get a copy of this message | ||
Hi Joan
Sorry for the late response.
On Thu, Dec 14, 2023 at 6:08 PM Joanhey <joanhey@kumbiaphp.com> wrote:
>
> We can't use sapi_module.read_post() from CLI.
>
> https://github.com/joanhey/AdapterMan
> This runtime use the CLI-SAPI, but this SAPI is very limited. We can use
> parse_str() easily for 'application/x-www-form-urlencoded' but we need
> to replicate in userland for 'multipart/form-data'.
>
>https://github.com/joanhey/AdapterMan/blob/master/src/Http.php#L410-L416
>
> https://github.com/joanhey/AdapterMan/blob/master/src/ParseMultipart.php
Yes, a web server written in PHP is indeed the one use-case for the
$input_stream parameter.
Looking at AdapterMan, it looks like you're handling requests as
strings. https://github.com/joanhey/AdapterMan/blob/4171d0218a253b2b4c178af067bd4601dd4daf80/src/ParseMultipart.php#L23
It doesn't seem like this would scale well for multipart requests. Do
you reckon this can be rewritten to use streams instead? Otherwise the
feature seems half-baked.
I'm going forward with the RFC as is. I'm not against re-adding
support for $input_stream at a later point in time. But it should be
demonstrated that AdapterMan can actually make good use of it.
Ilija