Contact Form 7

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 ␣http://example.com␣ (a valid URL with leading and trailing whitespaces) into a URL field causing no validation error, inputting ␣example@example.com␣ (a valid email with leading and trailing whitespaces) into an email field fails with a 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 ␣example@example.com␣ 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.

All our products that engage in user input validation (Contact Form 7, Schema-Woven Validation, etc.) are going to comply with this new policy.