#19705: CommonMiddleware handles If-None-Match incorrectly
-------------------------------+------------------------------------
Reporter: aaugustin | Owner: syphar
Type: Bug | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by syphar):
Just rediscovered this issue.
* We refactored the conditional-get handling in
7a40fef17ab7918cbb1ddc3ba080f42b420f7a48. There we merged all the
different implementations of conditional-get handling into one place.
* there, based on the original code, a new response is generated as not-
modified. Only cookies are kept if they are there.
* I just started working on a new ticket that will deprecate / remove
{{USE_ETAGS}} setting, and get the conditional-get handling out of
{{CommonMiddleware}}. Then the {{ConditionalGetMiddleware}} will generate
a {{ETag}} if there is none. By this middleware just being the last one,
many of the edge-cases will be fixed.
Is there any knowledge on if we should keep all the headers in a 304
response? Before the refactor we had places that handled it differently.
At the moment we're returning a new 304 response all the time.
--
Ticket URL: <https://code.djangoproject.com/ticket/19705#comment:13>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.40fd44f362bb6f0fe64096514d1f880d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
