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

From: Date: Sat, 07 Oct 2023 12:20:38 +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-121262@lists.php.net to get a copy of this message
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 exactly fit there. But seems better than html functions (where it's placed in > the 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

« previous php.internals (#121262) next »