id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
27344	ConditionalGetMiddleware should only operate on GET requests	Kevin Christopher Henry	Kevin Christopher Henry	"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."	Bug	assigned	HTTP handling	1.10	Normal				Ready for checkin	1	0	0	0	0	0