As long as we’re working good enough according to the general standard, I don’t think this is a valid feature request or a bug report.
I disgree with this. Not sure what your use-case is, but I’m not sure why your users need to care about the query params in the URL. In most cases, browsers handle the URL encoding themselves, it’s only the decoding that’s 1 extra step. If you’re building a UI or something, you can anyways show the correct value to the users.
I think it says “often used to carry xyz” in the form of key=value. The often applies to carrying information and not to the form. The form seems to be well-defined.
In any care, what’s the use case here? What makes you go against a standard and try to implement something that can’t be achieved with the standards? The URL needs to be encoded is not a valid argument as that’s how it should be. Websites all over the world use encoded URLs in query params, so I’m interested to know the problem you’re trying to solve here.
This behaviour has been fixed and standardized across all our services (Functions, Edge Functions, Cloud and CLI). The fix affects the encoding of request.url, when there’s commas in the search query. Consider a request to /products?1,2,3. For reasons, our CDN turns that into /products?1%2C2%2C3. Now with this change rolled out, it’s turned back into /products?1,2,3 in Edge Functions, so devs are seeing the request exactly as it comes in from the browser.
Regarding the original reported issue the devs mentioned the following:
There might be some misunderstanding here on what the expected behaviour is in the example shared: