Do not add cache control header if is set to false or a falsy value

[Wiktor]

Currently when one sets no_cache to a falsy value, e.g.:

@cache_control(no_cache=False)
def some_view()
    pass

Cache-Control header will be set to no_cache=False.

This might be confusing and might lead to a security issue.

Instead it should be just excluded.

[Wiktor]

PR: ​https://github.com/django/django/pull/16099

[Jan Urban]

This ticket is about avoiding the possible misunderstanding of how no-cache works in browser.
This ticket should not change the functionality of no-cache header and the end result of the patch_cache_control and how the header is interpreted. (As far as I know)

Needs more verification and discussion, if we should lead the hand of others.
As mentioned as it could be security issue as well if the value is interpreted wrongly by the others.

I do not know how exactly the no-cache works and what are the conventions for it and best practice, but this sounded like it make it more explicit.

[Mariusz Felisiak]

Closing as "needsinfo" as I'm not sure how this can create a security issue and why False should be treated differently. True always takes precedence over other values, so passing False will not override. On the other hand when no-cache is not set to True than the value is cast to string and added to the list of field names. Please provide more details.

[Wiktor]

Setting

no_cache = False
cache_control(no_cache=no_cache) 

will end up creating header

Cache-Control: no-cache=False

which is not intuitive and might lead to an unexpected caching behavior (thus I mentioned potential security issue). What I'd expect is an empty Cache-Control.

Cache-Control:  

More context about no-cache could be found in RFC: ​https://www.rfc-editor.org/rfc/rfc7234#section-5.2.2.2

The "no-cache" response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful
validation on the origin server. This allows an origin server to
prevent a cache from using it to satisfy a request without contacting
it, even by caches that have been configured to send stale responses.
[...]

For True it works as expected (it just adds Cache-Control: no-cache).

What do you suggest in that case? I understand that maybe the behavior should be changed for all the keyword arguments (True - turn them on, False - turn them off), however I find no-cache more sensitive.