Changes between Initial Version and Version 3 of Ticket #27344


Ignore:
Timestamp:
Oct 15, 2016, 6:22:38 PM (8 years ago)
Author:
Kevin Christopher Henry
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #27344

    • Property Has patch set
    • Property Owner changed from nobody to Kevin Christopher Henry
    • 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  
    11With 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.
Back to Top