Taffy icon indicating copy to clipboard operation
Taffy copied to clipboard
verified publisher icon atuttle

Support `If-Match` ETag usage, inverse of already supported `If-None-Match`

Open atuttle opened this issue 11 years ago • 3 comments

We already support If-None-Match ETag usage, it should be pretty easy to add support for If-Match, too.

atuttle avatar Dec 17 '14 04:12 atuttle

I have the basics of a PR for this done and tested, but looking at the spec has brought up a few questions.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24

  1. The spec supports sending multiple E-Tags, and if any of them match then the request continues. Currently it doesn't look like If-None-Match code currently supports multiples - is that something we want to support for this iteration? If so, do we want to go ahead and support it for If-None-Match as well?
  2. The spec also states that If-Match: * MUST NOT be performed if the representation does not exist - to me that means if the request is trying to return a 404 and the client sends If-Match: *, we should intercept and return a 412 instead. Do you think thats right?
  3. The current If-None-Match functionality is only applied to GET requests - are you only wanting to support If-Match for GETs as well, or are you wanting to extend support to other verbs? If so, we will probably need to have a discussion on how to implement.

ryanguill avatar Dec 21 '14 02:12 ryanguill

  1. I don't think we need to support multiple values. The way that the ETag values Taffy sends are generated, there should only ever be one.
  2. In the case of a would-be 404, I think a 404 response is still more appropriate than a 412. I think the spec is saying that when a 404 would be returned, but the if-match header would result in a 412, use the 404.
  3. I could see if-match being useful for DELETE, PUT and PATCH too. Not so sure about POST.

atuttle avatar Jan 20 '15 00:01 atuttle

  1. sounds good
  2. sounds good
  3. I have committed the code that implements If-Match with GETs only so you can take a look if you want. As mentioned, the current ETag functionality only supports GETs, so if lets discuss the best way to proceed to support mutable actions. GET, HEAD, PUT and DELETE are supposed to be idempotent, but POST and PATCH aren't - (and can we really expect that everyone who wants to implement ETags will implement PUT and DELETEs properly? What if I don't want to support ETags on anything but GETs? What are the ETags value for non-GETs, still the hash of the response? What if there is no response, just a status code?

ryanguill avatar Jan 20 '15 01:01 ryanguill