6 ms·

Why is this bad? for example if you have an Image you want to both DELETE and GET, and have cache control, once it's cached, the DELETE will return the bytes of

Why is this bad? for example if you have an Image you want to both DELETE and GET, and have cache control, once it's cached, the DELETE will return the bytes of the image without going to the server...

binarycrusader 14y ago
Because the HTTP 1.1 specification says it should behave differently, and developers expect clients to comply with the specification.
- eranation 14y ago
  Sorry, I was commenting on my own post and wanted to provide an example for "why this is bad" and not ask "why is this bad" apparently, HN also teaches me English (not my native language)
daliusd 14y ago
I think RFC covers this: From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html Section "9.1.2 Idempotent Methods". "However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent." As well section "9.7 DELETE". The last sentence: Responses to this method are not cacheable. The same in human language: there is no guarantee that you are deleting the same object because its ID matches. E.g. MD5 collisions are rare but they sometimes happen.
eloisius 14y ago
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.
darklajid 14y ago
I wonder why three people answered your question, not understanding that you - submitted the link in the first place - tried to provide an explanation why this is a bad idea (i.e. wrong) and telling you that this behavior is, in fact, not according to the specs. Communication failure? Maybe it would help to clarify your statement a bit? Edit: Reading a third and forth time I'm becoming less certain that _I_ got your point and the others didn't (note to self: That shouldn't be the default assumption). Did you really ask why that is bad? Edit 2: Looking at your username and the issue comments I kind of assume that you are the commenter over at code.google.com, calling this 'severe'. So I'm back to my original assumption that you know perfectly fine why this is bad.
- biot 14y ago
  The question "Why is this bad?" can be interpreted two ways: both as "Can someone please tell me why this is bad?" and "Why is this bad, you might be wondering? Let me tell you..." Ambiguities like this are sometimes amusing, such as when a reply saying "Love it!" can be read as both "[I] love it!" and the imperative command "[You must] love it!"
  - eranation 14y ago
    Yep, bad choice of English words from my side. not may native language... yep, I was trying to explain why it's bad, not asking why it is bad... :)
    - sp332 14y ago
      It's pretty subtle :) The closest way to do it is like this: Why is this bad? Well, for example if you have an Image... Just put the word "well," between the question and the explanation. I doubt they put that in a textbook though :)
      - eranation 14y ago
        thanks! next time I will... ;)
eranation 14y ago
Yes, bad English from my end! Please read it as "Why this is Bad: ", and not "Why is this bad?"... Thanks for all the ones who corrected me!
zaptheimpaler 14y ago
So to clarify, the problem is that browser serves the cached copy of the response from the GET request to the user, meaning that the user will not see the possibly different response returned by the server for the DELETE request correct? I feel like I'm missing something here.
- darklajid 14y ago
  No, the browser doesn't actually send the DELETE in the first place..
  - corford 14y ago
    Just to be clear (because I feel like I'm missing something here as well): the problem is if you allow a GET to be cached and then the client makes a DELETE request on that cached resource, Chrome applies the DELETE to the cached version and doesn't propagate the request to the server??
    - eranation 14y ago
      From the logs it seems to me it doesn't do a DELETE and sends a "GET (from cache)" type of request

binarycrusader 14y ago

Because the HTTP 1.1 specification says it should behave differently, and developers expect clients to comply with the specification.

eranation 14y ago
Sorry, I was commenting on my own post and wanted to provide an example for "why this is bad" and not ask "why is this bad" apparently, HN also teaches me English (not my native language)

daliusd 14y ago

I think RFC covers this: From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html Section "9.1.2 Idempotent Methods". "However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent." As well section "9.7 DELETE". The last sentence: Responses to this method are not cacheable. The same in human language: there is no guarantee that you are deleting the same object because its ID matches. E.g. MD5 collisions are rare but they sometimes happen.

eloisius 14y ago

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.

darklajid 14y ago

I wonder why three people answered your question, not understanding that you - submitted the link in the first place - tried to provide an explanation why this is a bad idea (i.e. wrong) and telling you that this behavior is, in fact, not according to the specs. Communication failure? Maybe it would help to clarify your statement a bit? Edit: Reading a third and forth time I'm becoming less certain that _I_ got your point and the others didn't (note to self: That shouldn't be the default assumption). Did you really ask why that is bad? Edit 2: Looking at your username and the issue comments I kind of assume that you are the commenter over at code.google.com, calling this 'severe'. So I'm back to my original assumption that you know perfectly fine why this is bad.

biot 14y ago
The question "Why is this bad?" can be interpreted two ways: both as "Can someone please tell me why this is bad?" and "Why is this bad, you might be wondering? Let me tell you..." Ambiguities like this are sometimes amusing, such as when a reply saying "Love it!" can be read as both "[I] love it!" and the imperative command "[You must] love it!"
- eranation 14y ago
  Yep, bad choice of English words from my side. not may native language... yep, I was trying to explain why it's bad, not asking why it is bad... :)
  - sp332 14y ago
    It's pretty subtle :) The closest way to do it is like this: Why is this bad? Well, for example if you have an Image... Just put the word "well," between the question and the explanation. I doubt they put that in a textbook though :)
    - eranation 14y ago
      thanks! next time I will... ;)

eranation 14y ago

Yes, bad English from my end! Please read it as "Why this is Bad: ", and not "Why is this bad?"... Thanks for all the ones who corrected me!

zaptheimpaler 14y ago

So to clarify, the problem is that browser serves the cached copy of the response from the GET request to the user, meaning that the user will not see the possibly different response returned by the server for the DELETE request correct? I feel like I'm missing something here.

darklajid 14y ago
No, the browser doesn't actually send the DELETE in the first place..
- corford 14y ago
  Just to be clear (because I feel like I'm missing something here as well): the problem is if you allow a GET to be cached and then the client makes a DELETE request on that cached resource, Chrome applies the DELETE to the cached version and doesn't propagate the request to the server??
  - eranation 14y ago
    From the logs it seems to me it doesn't do a DELETE and sends a "GET (from cache)" type of request