#32531: Cache key not learnt for 304 responses — view must keep redoing work
until
"fresh" request comes in!
------------------------------------+--------------------------------------
Reporter: Nathan Vander Wilt | Owner: nobody
Type: Uncategorized | Status: new
Component: HTTP handling | Version: 3.1
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------------+--------------------------------------
Comment (by Nathan Vander Wilt):
Ah, this might be invalid. While the `CacheMiddleware` does handle 200 vs.
304 somewhat differently throughout its own logic, my impression is that
the developer simply don't intend `ConditionalGetMiddleware` to work well
and it is the real culprit here.
The <https://docs.djangoproject.com/en/3.1/topics/conditional-view-
processing/#comparison-with-middleware-conditional-processing> discussion
referencing it warns:
> It doesn’t save you from generating the response, which may be
expensive.
and implies the goal of ± ETag handling is only much more modest such
that:
> […] the amount of network traffic sent back to the clients will still be
reduced if the view hasn’t changed.
Feel free to close as invalid if this is indeed the case.
--
Ticket URL: <https://code.djangoproject.com/ticket/32531#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.10090d4ef72e18c678bc1fce3445ac09%40djangoproject.com.
