4 ms·

I'm not sure if you're trolling or not, so I'll assume naiveté and give you a thoughtful answer: Because the resource you tried to delete will not be deleted. T

I'm not sure if you're trolling or not, so I'll assume naiveté and give you a thoughtful answer: Because the resource you tried to delete will not be deleted. To add insult to injury, from a UI perspective, it will still behave like it has been. This wrecks any ajax applications that cache GET requests. Furthermore, it's in direct violation of the HTTP spec: > If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable. [http://www.ietf.org/rfc/rfc2616.txt http://www.ietf.org/rfc/rfc2616.txt]

thrill 14y ago
SHOULD is not MUST
- piotrSikora 14y ago
  Why is he being downvoted? As per RFC2119 (http://www.ietf.org/rfc/rfc2119.txt http://www.ietf.org/rfc/rfc2119.txt): 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
  - masklinn 14y ago
    Because the problem goes beyond failing to invalidate the existing cache for the resource (which is a SHOULD), Chrome does not even make the request, which most definitely isn't acceptable under any circumstance, even after careful considerations. The spec even emphatically says that responses to a DELETE are not cacheable, how could you use an existing cached response as valid for a DELETE if you are not allowed to cache a delete in the first place?
- zcvosdfdgj 14y ago
  Then there is a PERIOD, and it says "Responses to this method are not cacheable." So caching DELETE is against the spec.
  - nagisa 14y ago
    But returning already cached GET response to DELETE request is not. I, however, agree that this behaviour shouldn't happen.
    - jerf 14y ago
      I believe the spec is saying that if you are a proxy, and you have a cached value for X, then you see a delete for X, you are allowed to immediately expire your entry for X. In other words, the proxy is permitted to assume that a delete request is so likely to result in a change on that resource that it may simply assume the cache is bad. It isn't required to, though. It does not mean that if you receive a DELETE request you can just substitute the value of what is a completely different request (the GET request). I believe eloisius is not correct about the spec banning this behavior with that line. It's "banned" because it's just broken, nonsensical. It's not the same request in the first place, any more than you can just substitute POST results for GET.
    - zcvosdfdgj 14y ago
      But returning already cached GET response to DELETE request is not. Yes, you're right.. the spec doesn't mention what should happen when the developer does something completely irrational, like returning a cached GET response to a DELETE request.
    - dingle_thunk 14y ago
      Yes, but mailing a bicycle to a random US address as a response to the DELETE request is also not explicitly forbidden in the spec. This doesn't mean that the spec provides for commercial suicide through bicycle mail.
eranation 14y ago
I commented on my own post to explain why I think it's bad, sorry for not reading it aloud to myself, I can understand why you read it not the way I had it in my head :) Should read my post as: "Are you asking why this is bad? it is bad because..." and provided an example... P.S. I like the Insult to injury quote, it's exactly how I felt when trying to debug it, took me an hour to figure that out...

thrill 14y ago

SHOULD is not MUST

piotrSikora 14y ago
Why is he being downvoted? As per RFC2119 (http://www.ietf.org/rfc/rfc2119.txt http://www.ietf.org/rfc/rfc2119.txt): 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
- masklinn 14y ago
  Because the problem goes beyond failing to invalidate the existing cache for the resource (which is a SHOULD), Chrome does not even make the request, which most definitely isn't acceptable under any circumstance, even after careful considerations. The spec even emphatically says that responses to a DELETE are not cacheable, how could you use an existing cached response as valid for a DELETE if you are not allowed to cache a delete in the first place?
zcvosdfdgj 14y ago
Then there is a PERIOD, and it says "Responses to this method are not cacheable." So caching DELETE is against the spec.
- nagisa 14y ago
  But returning already cached GET response to DELETE request is not. I, however, agree that this behaviour shouldn't happen.
  - jerf 14y ago
    I believe the spec is saying that if you are a proxy, and you have a cached value for X, then you see a delete for X, you are allowed to immediately expire your entry for X. In other words, the proxy is permitted to assume that a delete request is so likely to result in a change on that resource that it may simply assume the cache is bad. It isn't required to, though. It does not mean that if you receive a DELETE request you can just substitute the value of what is a completely different request (the GET request). I believe eloisius is not correct about the spec banning this behavior with that line. It's "banned" because it's just broken, nonsensical. It's not the same request in the first place, any more than you can just substitute POST results for GET.
  - zcvosdfdgj 14y ago
    But returning already cached GET response to DELETE request is not. Yes, you're right.. the spec doesn't mention what should happen when the developer does something completely irrational, like returning a cached GET response to a DELETE request.
  - dingle_thunk 14y ago
    Yes, but mailing a bicycle to a random US address as a response to the DELETE request is also not explicitly forbidden in the spec. This doesn't mean that the spec provides for commercial suicide through bicycle mail.

eranation 14y ago

I commented on my own post to explain why I think it's bad, sorry for not reading it aloud to myself, I can understand why you read it not the way I had it in my head :) Should read my post as: "Are you asking why this is bad? it is bad because..." and provided an example... P.S. I like the Insult to injury quote, it's exactly how I felt when trying to debug it, took me an hour to figure that out...