#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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
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.
