Minor: Reason(s) for different semantics in CoAP response codes

[mkovatsc]

In CoAP, the cacheability of a response depends on the response code (e.g., responses with code 2.04 are cacheable). This difference also leads to slightly different semantics for the codes starting with 2; for example, CoAP does not have a 2.00 response code whereas 200 ("OK") is commonly used with HTTP.

Is it really that difference that leads to the 2.xx semantics of CoAP?

[ektrah]

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.

[mkovatsc]

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.

[mkovatsc]

During this, I stumbled over the question how 4.01 Unauthorized and 4.03 Forbidden can be cacheable..
@ektrah ?

[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.)

[ektrah]

For some error response codes, the CoAP Max-Age Option is actually closer to the HTTP Retry-After header field.

[mkovatsc]

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?

[ektrah]

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).

[mkovatsc]

• What could be NOT "something else" to authenticate/authorize?
• Could anyone other than the origin server know what else to put into the cache key?

I am not sure we are heading to something useful here, but it also feels related to #65.

[ektrah]

• For example, a query string or some new CoAP option with a bearer token
• I’d say everyone (including the origin server) must know (and agree) what to put in the cache key. For example an intermediary with a cache can serve a fresh, cached response to a new client. If the intermediary doesn’t include authorizations in the cache key, it might leak information meant for an authorized client when acting on behalf of another, unauthorized client.