Changes between Initial Version and Version 3 of Ticket #27344
- Timestamp:
- Oct 15, 2016, 6:22:38 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #27344
- Property Has patch set
- Property Owner changed from to
- Property Type Uncategorized → Bug
- Property Triage Stage Unreviewed → Ready for checkin
- Property Summary ConditionalGetMiddleware should not operate on unsafe requests → ConditionalGetMiddleware should only operate on GET requests
-
Ticket #27344 – Description
initial v3 1 1 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. 2 3 `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: 4 5 > 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.