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
32531	"Cache key not learnt for 304 responses — view must keep redoing work until ""fresh"" request comes in!"	Nathan Vander Wilt	nobody	"Discovered an interesting situation that's easy to hit in a development environment but might result in some wasted work in a production setting too. Consider this situation:

* I load a Django-rendered page in my browser. This browser keeps its own cache of the rendered response and its ETag.
* The Django cache on the serverside gets flushed somehow (e.g. if it's a `LocMemCache` and I'm using `runserver` this happens whenever I touch a file…)
* Now I (gently) referesh the page in my browser and it sends a request with `If-None-Match` and the ETag that it knows for the page.
* Since the cache was flushed the view has to render the page again. In this scenario the page hasn't changed, so after the render happens, the ETag matches — hooray! The browser gets a 304 Not Modified response back.

But here's the problem: the next time I gently refresh the browser (i.e. allow it to use its usual caching) the last step is repeated in whole! That is, the view can end up rendering the page AGAIN and AGAIN and each time the ETag matches in the end but Django does not seem to remember that.

As soon as a ""fresh"" request comes in, i.e. a more aggressive refresh from the browser that disables it's cache and yields a 200 response back, all subsequent ""gentle refresh"" responses then get a 304 *without* the view having to re-render.

I suspect that the culprit might be related to the logic in `UpdateCacheMiddleware.process_response` which will only call `learn_cache_key` when the `response.status_code == 200`?"	Uncategorized	closed	HTTP handling	3.1	Normal	invalid			Unreviewed	0	0	0	0	0	0