[core] draft-ietf-core-etch: Response Code for FETCH

[Kovatsch Matthias]

Hi all

I am currently adding etch support to Copper and read the following:

" FETCH cannot be assumed to be a complete representation
of the resource identified by the effective request URI, i.e., it
cannot be used by a cache as a payload to be returned by a GET
request."

Too bad that:

"Unlike HTTP, the cacheability of CoAP responses does not depend on
the request method, but it depends on the Response Code. " [RFC 7252]

Thus, we need a proper Response Code for FETCH. However, which one? "Changed" is a bit ill-suited for a safe method...
Currently text on this is completely missing. Examples will have to be fixed.

Ciao
Matthias

[Carsten Bormann]

The FETCH payload is part of the cache key.
(Penultimate paragraph of intro to Section 2.)
Shouldn’t that solve your problem?

Grüße, Carsten

Post by Kovatsch Matthias
Hi all
" FETCH cannot be assumed to be a complete representation
of the resource identified by the effective request URI, i.e., it
cannot be used by a cache as a payload to be returned by a GET
request."
"Unlike HTTP, the cacheability of CoAP responses does not depend on
the request method, but it depends on the Response Code. " [RFC 7252]
Thus, we need a proper Response Code for FETCH. However, which one? "Changed" is a bit ill-suited for a safe method...
Currently text on this is completely missing. Examples will have to be fixed.
Ciao
Matthias

[Kovatsch Matthias]

Post by Carsten Bormann
The FETCH payload is part of the cache key.
(Penultimate paragraph of intro to Section 2.) Shouldn’t that solve your
problem?

Were payloads considered for the cache key before? I guess, it would need some proper write-up and education for that (including the update of potentially installed caches).

Would that mean all request payloads? This would make 2.05 responses to POST also cacheable, which might be a feature and maybe fix CoAP servers that use 2.05 in response to a POST unknowingly...

Best wishes,
Matthias

[Carsten Bormann]

Post by Kovatsch Matthias

Post by Carsten Bormann
The FETCH payload is part of the cache key.
(Penultimate paragraph of intro to Section 2.) Shouldn’t that solve your
problem?

Were payloads considered for the cache key before? I guess, it would need some proper write-up and education for that (including the update of potentially installed caches).

I don’t think so. E.g., a POST payload often is large, making it less useful as a cache key.
(More importantly, POST isn’t idempotent; this would have needed an iPOST or some such.)

Post by Kovatsch Matthias
Would that mean all request payloads? This would make 2.05 responses to POST also cacheable, which might be a feature and maybe fix CoAP servers that use 2.05 in response to a POST unknowingly…

Let me cite that penultimate paragraph from RFC 8132:

Depending on the response code as defined by [RFC7252], the response
to a FETCH request is cacheable; the request body is part of the
cache key. Specifically, 2.05 (Content) response codes (the
responses for which are cacheable) are a typical way to respond to a
FETCH request.

So this is FETCH only. And it (tries to) say that 2.05 should work very well with that.

Grüße, Carsten

[Kovatsch Matthias]

Post by Kovatsch Matthias

Post by Kovatsch Matthias
Were payloads considered for the cache key before? I guess, it would need

some proper write-up and education for that (including the update of
potentially installed caches).
I don’t think so. E.g., a POST payload often is large, making it less useful as a
cache key.
(More importantly, POST isn’t idempotent; this would have needed an iPOST or some such.)

Well, I guess it is hard to categorize this globally... There might be service resources that convert values from one unit to another and probably many more use cases for small POST payloads and a cacheabe response.

My idea was that a proper write-up could tell server implementers that they should respond with 2.05 when their POST resource handler is indeed idempotent/cacheable and 2.04 otherwise. This was for me the benefit of linking cacheability to the response code in the first place... What was the main reason for this?

Post by Kovatsch Matthias
Depending on the response code as defined by [RFC7252], the response
to a FETCH request is cacheable; the request body is part of the
cache key. Specifically, 2.05 (Content) response codes (the
responses for which are cacheable) are a typical way to respond to a
FETCH request.
So this is FETCH only. And it (tries to) say that 2.05 should work very well with that.

The problem I see is that so far, the message was: when you implement a cache only look at the response code and use the request options for the cache key. Now we have an extension draft that also requires cache implementers to look at the request method...

[Klaus Hartke]

the only viable way
right now is to always include the request method, all applicable
request options, and the request payload in the cache key.

Unless we update RFC 7252 with something like this:

+---------------------------------+-----------+---+---+---+
| Response Code | Cacheable | M | O | P |
+---------------------------------+-----------+---+---+---+
| 2.01 Created | no* | | | |
| 2.02 Deleted | no* | | | |
| 2.03 Valid | no* | | | |
| 2.04 Changed | no* | | | |
| 2.05 Content | yes | x | x | x |
| 4.00 Bad Request | yes | x | x | x |
| 4.01 Unauthorized | yes | x | x | |
| 4.02 Bad Option | yes | x | x | |
| 4.03 Forbidden | yes | | x | |
| 4.04 Not Found | yes | | x | |
| 4.05 Method Not Allowed | yes | x | | |
| 4.06 Not Acceptable | yes | x | x | |
| 4.12 Precondition Failed | yes | x | x | |
| 4.13 Request Entity Too Large | yes | x | x | x |
| 4.15 Unsupported Content-Format | yes | x | x | |
| 5.00 Internal Server Error | yes | x | x | x |
| 5.01 Not Implemented | yes | x | x | x |
| 5.02 Bad Gateway | yes | x | x | x |
| 5.03 Service Unavailable | yes | | | |
| 5.04 Gateway Timeout | yes | | | |
| 5.05 Proxying Not Supported | yes | x | x | |
+---------------------------------+-----------+---+---+---+

* = not cacheable, but has some effect on cache entries;
M = request method is part of the cache key;
O = applicable request options are part of the cache key;
P = request payload is part of the cache key.

Klaus

[Kovatsch Matthias]

For a presented request, a CoAP endpoint MUST NOT use a stored
o the presented request method and that used to obtain the stored
response match,
[...]
So the request method is already always part of the cache key.

Okay, I guess the whole beauty I expected behind this "Unlike HTTP" philosophy is actually not there. A FETCH without payload cannot be answered with a perfectly nice 2.05 in the cache, a GET cannot be answered with a 2.05 from a response to POST, etc.

Caching appears to be a bit too complex to florish without a new document... Puh, if only there was time.