Open mkovatsc opened 2 years ago
Yes, I think so. In HTTP, the cacheability of a response depends on the request method and 200 OK is used for practically all methods. In CoAP, the cacheability of a response depends on the response code (so that, for example, a 4.29 Too Many Requests response can be reused even for a POST request) and we separated the success cases into 2.05 for GET, 2.01/2.04 for PUT/POST, and 2.02 for DELETE.
In PR #74 , I rewrote the text, as the main message is probably that in CoAP the response code ALONE decides cacheability, while HTTP has complex rules.
During this, I stumbled over the question how 4.01 Unauthorized and 4.03 Forbidden can be cacheable.. @ektrah ?
According to the Stateless constraint, all requests must be self-containing. So, if you’re not authorized to access a resource when making a request the first time, you’re also not authorized when making the same request again. (Of course, the server should set an appropriate Max-Age so that you’re not stuck with the cached response forever.)
For some error response codes, the CoAP Max-Age Option is actually closer to the HTTP Retry-After header field.
The issue I see is, how could the request and its fields that are evaluated by the cache carry any authorization or authentication information? I would say there is none and auth* information always comes from from something else, so returning a cached response just breaks the application, no?
If “auth* information always comes from something else” then “something else” must be part of the cache key (or like a change in DTLS epoch that keeps cache entries apart).
I am not sure we are heading to something useful here, but it also feels related to #65.
Is it really that difference that leads to the 2.xx semantics of CoAP?