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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
