On its user input validation, Contact Form 7 has basically emulated the HTML specification and major browser implementations. However, there is a problem. They don’t handle surrounding whitespaces in a consistent way.
For example, while you can input
(a valid URL with leading and trailing whitespaces) into a URL field causing no validation error, inputting ␣
http://example.com␣
(a valid email with leading and trailing whitespaces) into an email field fails with a
example@example.com␣
␣
typeMismatch
error.
Another example can be found in a required field. If you leave a required field blank, you will get a valueMissing
error. You can pass the validation by inputting any characters, even whitespaces. For many people, the fact that whitespaces pass a required field validation would be counterintuitive.
In sum, some validity checks run after stripping surrounding whitespaces, while others do not.
Solution: Introduce a consistent policy
To avoid this problem, we introduce our own policy of surrounding whitespaces handling, instead of automatically complying with the HTML spec.
The policy is as follows: Before applying a validation, strip leading and trailing whitespaces from the user input value, regardless of the field type or the validation rule type. This “whitespaces” is not merely the ASCII space character (U+0020), but includes all whitespace characters that Unicode defines.
Based on this policy, every validation rule will be applied after stripping surrounding whitespaces, thus
in the previous example will be accepted as a valid email, and a required field will not accept a user input consisting only of whitespace characters.
example@example.com␣
␣
All our products that engage in user input validation (Contact Form 7, Schema-Woven Validation, etc.) are going to comply with this new policy.