Changing the order would be a BC break (with no good way to warn about it).
And making the order dependent on the ini setting would make the order unknown to libraries (as they don't control the ini setting), which would make it a weird API.

If you want an utility method respecting the ini setting, you can implement it in your project as a function getting the Request object as argument. All parameter bags used in your implementation are available publicly.

yes, the BC break is problematic. It would definitely be better as a separate function, the only question is what would be a good name for it...

Regarding weird API: I would say not any weirder than PHP itself, and it's not like nothing else in Symfony changes when php.ini values are changed.

Also, I think the current implementation has significant footgun potential: Let's say you have some POST form on your site and decide to read the data with $request->get() (or maybe you use some library that uses that without you knowing). then I can trivially break your functionality by sending people links like "/contact-form?message=bla": For the user filling out the form, there's no way to tell that something is off, but whatever they put into the message field will get lost on submit

Or to make it more explicit: I send the user a link like /order?selectedproduct=ultra-deluxe-edition. User fills out the order form, selects the "free trial" product, and then gets a gigantic unexpected invoice. Looking at GET before POST opens you to all kinds of attacks, I can't currently think of a situation where it would be a good idea to do that

getting the wrong GET param can go equally wrong too. Note the default variable order in PHP is also GP.

IMHO the only sane answer is to deprecate Request::get()

@ro0NL yes, the default order is GP, and

Registration is done from left to right, newer values override older values.

so P takes precedence over G

@flack the fact that PHP itself has a weird API does not mean that Symfony should provide an equivalent. Note that by modern standards of PHP RFCs, the $_REQUEST superglobal with a behavior being dependant on an ini setting would probably be rejected.

Let's say you have some POST form on your site and decide to read the data with $request->get()

to me, that's the actual issue. If you know that you want to read a POST data, use the dedicated API doing that.

IMHO the only sane answer is to deprecate Request::get()

I would totally vote for it. In my own projects, usages of Request::get() have been banned 10 years ago.

to me, that's the actual issue. If you know that you want to read a POST data, use the dedicated API doing that.

Well, if you're using a library, you may not even be aware that you're using it. Also, see my original example with paginated search results. At least in sites I work on, pagination usually makes a query string out of the search form, and to do a new search, you would send the form again, which typically uses POST (at least from what I see). So I would say there's a usecase for POST with a fallback to GET, but not the other way around.

But yes, i would also vote to deprecate the current get function. And maybe make some new function that emulates $_REQUEST or some sane subset of it, to help out projects migrating from the dark ages to current design paradigms

adding something that emulates $_REQUEST doesnt help migrating away from it ;)

and to do a new search, you would send the form again, which typically uses POST (at least from what I see)

well, search forms are often implemented as <form method="GET> precisely because a search is something where it makes sense to use a GET request with the term in the query string (also, it makes the search result page potentially cacheable)

well, search forms are often implemented as <form method="GET> precisely because a search is something where it makes sense to use a GET request with the term in the query string (also, it makes the search result page potentially cacheable)

yeah, like I said, that's mostly from sites I see (or work on), and the rationale for POST in the form is precisely to avoid hitting a cache.

Anyhow, should I make a "Deprecate Request::get()" ticket? If nobody likes my $_REQUEST emulation, I can also implement it on my side, it's only a few lines anyways :-)

closing in favor of #40984

My 2c: search forms in an ideal world should use GET 99% of the time, but sometimes they hit max length of URL allowed by browsers, proxies, reverese-proxies or webservers, esp. when adding in faceting. This is often found after the initial build, and quick-fix is then to switch the search form to POST, possibly even in JS. This is one of the cases where being able to conflate GET with POST on the receiving end actually makes sense ;-)