There a misconfigured CACHE_MIDDLEWARE_SECONDS setting leads to a wrong ‘Cache-Control’: ‘max-age=2.0’ header.
At first I thought it would be a good idea to just cast this to an int (like in this ticket #31982 (Convert max_age to an int in set_cookie()) – Django)
But then in another ticket #35041 (DATA_UPLOAD_MAX_MEMORY_SIZE causes a confusing error when not an integer) – Django this was rejected:
We have dozens of settings and we cannot add type checks for all of them to the Settings. Especially when an expected type is clearly documented.
So I head the idea to use the system check to look for sane setting types at the start. In the example above the output would be something like this:
System check identified some issues:
?: (files.W001) The type of CACHE_MIDDLEWARE_SECONDS should be int (default 600). see https://docs.djangoproject.com/en/dev/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS
For some misconfigured settings there will still be an explicit ImproperlyConfigured exception raised (like The ALLOWED_HOSTS setting must be a list or a tuple) or an implicit exception like AttributeError: ‘int’ object has no attribute ‘find’ when for example set LANGUAGE_CODE to an int.
The implementation checks the type of the default value against the type of the user setting and issues a warning if they don’t match. This works for most settings, since they do have a default value other than None. For the ones that have None as the default value, a table is present, that contains the expected default values.
Some poc code is here: Check settings types during systems checks · e11bits/django@c05225c · GitHub
Is this something people would find useful? Should I go forward with this and create a PR?