Hey, I'm not sure if this is bikeshedding, but the concept of parsing
bodies for non-POST requests lands really close to a proposal for adding a
QUERY method to the HTTP standard.
Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body
Discussion:
https://github.com/httpwg/http-extensions/labels/safe-method-w-body

It's meant to address the recent need for complex querying (GraphQL /
Elastic Search) that necessitates using POST but loses the default caching
of GET.
I think this RFC could serve as the groundwork for supporting QUERY if it's
extended to other MIME types in the future as Larry suggested. But QUERY
probably still has years to go before there is a consensus on it (I think
it's been talked about for 6+ years now)

On Tue, Dec 5, 2023 at 2:29 PM Ilija Tovilo <tovilo.il...@gmail.com> wrote:

> Hi everyone
>
> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo <tovilo.il...@gmail.com>
> wrote:
> >
> > I'd like to announce an RFC that proposes adding a new function called
> > parse_post_data() to expose the existing functionality to userland, so
> > that the mechanism can be used for other HTTP verbs.
> >
> > https://wiki.php.net/rfc/rfc1867-non-post
>
> I took a closer look at RoadRunner regarding file uploads and noticed
> that $input_stream will not be useful to it after all. RoadRunner
> handles files directly in its Go server by parsing the multipart body,
> storing any files to disk, and only transferring the file handles
> (along with any post data) to the PHP workers. New SAPIs could instead
> tweak sapi_module.read_post() when handling a new request. We can add
> these parameters if somebody can present a valid use-case, for now I
> opted to remove the $input_stream and $content_type parameters.
>
> Please let me know if you have any more feedback. I will wait at least
> 2 weeks before going forward with a vote, as this is a bigger change
> to the RFC.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Reply via email to