request.form uses urllib.parse_qs which does not persist blank values by default when requests submit application/x-www-form-urlencoded data

[pobk]

Describe the bug
This seems to be an acknowledged limitation of parse_qs, but I'm raising as a bug as this introduces undesired behaviour rather than adding new features.

While request.get_args and and request.get_query_args accept the keep_blank_values argument in order to persist blanks, request.form does not provide an interface to persist blank values.

My assertion is that a framework should not remove data simply because it doesn't have a value.

Relevant anecdote: Twilio webhooks submit a POST request using application/x-www-form-urlencoded encoded body. The body includes all values including some potentially blank/empty values.

When the request is processed by Sanic, it is decoded using urllib.parse_qs and does not have a mechanism to allow blank elements to persist. This results in missing elements from the request when accessing the variables from request.form.

In my case, the elements from the submission are relevant to generate a signature for request validation (see https://www.twilio.com/docs/usage/security). The signature is constructed using SHA1 hash of the submitted request key/value pairs and missing pairs generates a different signature to that expected.

In this instance, I have been receiving requests which include two elements that, depending on the hook, may or may not have a value.

Expected behavior
All variables, irrespective of existence of a value should be passed to the application.

Environment (please complete the following information):

• Version v22.3.0

[sjsadowski]

@pobk Thanks for the heads up. I agree that we should not be dropping blank values as the parameter in and of itself is a value that may be necessary.

[prryplatypus]

Just popping here to say that changing its behaviour now is probably a breaking change.

A different approach to avoid sudden breaking changes could be adding a method like get_query_args but for get_form_args, to which users can pass arguments for the parse_qs method.

If we want to change the behaviour of the .form attribute, we could also add a warning when accessing the .form attribute warning users that from a certain version we will no longer omit blank values by default, although in that case we would probably want to do the same with any other attributes (e.g.: query strings) for consistence.

[sjsadowski]

This can be done as a non-breaking change where the behavior defaults to what it is currently, which should be fine. Already working on it, just need some tests before I submit a PR.