#17834: ETag generated from empty content can break http caching
-------------------------------+------------------------------------------
Reporter: Paul Egan | Owner: Dwight Gunning
Type: Bug | Status: assigned
Component: HTTP handling | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------------
Changes (by Kevin Christopher Henry):
* cc: k@… (added)
Comment:
For reference, here's what the updated
[https://tools.ietf.org/html/rfc7232#section-2.1 RFC 7232] specification
has to say on the matter:
> A "strong validator" [like the ETags we compute] is representation
metadata that changes value whenever a change occurs to the representation
data that would be observable in the payload body of a 200 (OK) response
to GET. A strong validator might change for reasons other than a change to
the representation data, such as when a semantically significant part of
the representation metadata is changed (e.g., Content-Type), but it is in
the best interests of the origin server to only change the value when it
is necessary to invalidate the stored responses held by remote caches and
authoring tools.
So, the specification does not require the `ETag` to change unless the
response body itself changes. It //could// change, if we know that a
change to the headers invalidates the response. Since the framework can't,
in general, know that, and since the specification cautions against
invalidating the response when it's unnecessary, my opinion is that the
status quo of basing the `ETag` only on the response body is fine.
(If we were to try and take the headers into account, though, it's worth
noting which headers they should be.
[https://tools.ietf.org/html/rfc7231#section-3.1 RFC 7231] defines the
representation metadata as the `Content-Type`, `Content-Encoding`,
`Content-Language`, and `Content-Location` headers.)
--
Ticket URL: <https://code.djangoproject.com/ticket/17834#comment:14>
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/066.6d77a4485a437793c4668433775ba4b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.