Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121262
MIME-Version: 1.0
References: <CAPyj-LD0EDYUZSOM=P9doSZRJ8LipSKKUSBHxV-bRbCV1QsYtQ@mail.gmail.com>
 <CAEKnhAGd2PtSdBiw1MiGt8H2FJVe_x3nFaN5ujMGAU=2a+wheQ@mail.gmail.com>
In-Reply-To: <CAEKnhAGd2PtSdBiw1MiGt8H2FJVe_x3nFaN5ujMGAU=2a+wheQ@mail.gmail.com>
Date: Sat, 7 Oct 2023 14:20:38 +0200
Message-ID: <CAPyj-LCVejoRPVMdaPzgbb3KotEVs5+V0k29VuFSW9sir7D9Kw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Under discussion] RFC1867 for non-POST HTTP verbs
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Jakub

>> https://wiki.php.net/rfc/rfc1867-non-post
>>
>
> It should probably explicitly mention that it uses the same inis like max=
_input_vars, max_file_uploads and max_multipart_body_parts.

Indeed, I will mention that. Thank you.

> It's kind of strange function as I can't decide where it should be placed=
. I think it might be better as a stream function if it accepts only stream=
. It means it could go to stream funcs and be called stream_parse_post_data=
 instead but not sure about. But not 100% sure about it as it doesn't exact=
ly fit there. But seems better than html functions (where it's placed in th=
e current PR) as it has nothing to do with html IMHO.

TBH I have no idea how it landed there. When I created the PoC I just
threw it in somewhere, but it's indeed an odd place. I'll try to find
something better.

I don't think stream is a great place, as the common case of not
providing an input does not operate on streams, but on
sapi_module.read_post() directly.

I also don't think rfc1867.c is a great place as Ben suggested,
because the invoked function is actually agnostic to the exact format.
Instead, we use the existing functionality that chooses the parser
based on the content type, which includes
application/x-www-form-urlencoded.

Ilija