Re: [RFC][Under discussion] RFC1867 for non-POST HTTP verbs

From: 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

« previous php.internals (#122168) next »