Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122168
MIME-Version: 1.0
References: <CAPyj-LD0EDYUZSOM=P9doSZRJ8LipSKKUSBHxV-bRbCV1QsYtQ@mail.gmail.com>
 <ea33032a-749b-e2a5-8e22-5a289b89d16b@kumbiaphp.com>
In-Reply-To: <ea33032a-749b-e2a5-8e22-5a289b89d16b@kumbiaphp.com>
Date: Wed, 17 Jan 2024 13:55:19 +0100
Message-ID: <CAPyj-LBceU1hYZE8tfwt6aa++V+W7GJpYesX1q1Cf+6yoJNcEA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Joan

Sorry for the late response.

On Thu, Dec 14, 2023 at 6:08=E2=80=AFPM Joanhey <joanhey@kumbiaphp.com> wro=
te:
>
> 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/4171d0218a253b2b4c178af=
067bd4601dd4daf80/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