id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
33338	Document that @never_cache and add_never_cache_headers() set the Expires header.	Andy Chosak	Marcelo Galigniana	"The [https://docs.djangoproject.com/en/dev/topics/http/decorators/#django.views.decorators.cache.never_cache documentation] for the `@never_cache` decorator says that it sets the Cache-Control header but neglects to mention that [https://github.com/django/django/blob/97e9a84d2746f76a635455c13bd512ea408755ac/django/utils/cache.py#L272-L277 it also sets] Expires to the current time (if not already set).

Looking at [https://github.com/django/django/blame/97e9a84d2746f76a635455c13bd512ea408755ac/django/utils/cache.py#L276 the git blame], the use of Expires for `@never_cache` seems to predate the more modern Cache-Control. Is Expires still needed/desired as part of `@never_cache`?

It also feels a little bit unexpected that if `@never_cache` is going to set Expires as part of its behavior that it would leave alone a pre-existing Expires header that was set to some far future value.

It would be good to add tests for this behavior to [https://github.com/django/django/blob/8806e8809e023017e6958b9fa0bbd960938e0a91/tests/decorators/tests.py#L496 the existing tests], both that Expires gets set if not already set and that, if already set, it doesn't get modified, if that is the desired behavior.
"	Cleanup/optimization	closed	Core (Cache system)	3.2	Normal	fixed	cache		Ready for checkin	1	0	0	0	1	0