#27344: ConditionalGetMiddleware should only operate on GET requests
-------------------------------------+-------------------------------------
Reporter: Kevin Christopher | Owner: Kevin
Henry | Christopher Henry
Type: Bug | Status: assigned
Component: HTTP handling | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Kevin Christopher Henry:
Old description:
> With unsafe methods (`PUT`, etc.) the appropriate conditional response
> would be a 412 Precondition Failed response, which should prevent the
> request from being carried out. But by definition
> `ConditionalGetMiddleware` acts after the response has been generated, so
> it’s too late. The PR below includes a regression test where the
> middleware inappropriately changes the response to a 412 after applying
> the unsafe operation.
New description:
With unsafe methods (`PUT`, etc.) the appropriate conditional response
would be a 412 Precondition Failed response, which should prevent the
request from being carried out. But by definition
`ConditionalGetMiddleware` acts after the response has been generated, so
it’s too late. The PR below includes a regression test where the
middleware inappropriately changes the response to a 412 after applying
the unsafe operation.
`ConditionalGetMiddleware` is not suitable for `HEAD` requests either.
`HEAD` responses should return the same headers (including the `ETag`) as
the corresponding `GET` response, but `ConditionalGetMiddleware` will only
see the empty response body of the `HEAD` response and so will compute the
wrong `ETag`. Trying to compare `ETags` in this situation is also
pointless, as [https://tools.ietf.org/html/rfc7232#section-5 pointed out]
in the specification:
> Although conditional request header fields are defined as being usable
with the `HEAD` method (to keep `HEAD`'s semantics consistent with those
of `GET`), there is no point in sending a conditional `HEAD` because a
successful response is around the same size as a 304 (Not Modified)
response and more useful than a 412 (Precondition Failed) response.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27344#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 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/065.f239bd7b6744cffc01f1f07233fbdbe6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
