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

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 4 Aug 2017 21:52:17 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 5 Aug 2017 00:00:47 +0200

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

> On Aug 4, 2017, at 23:52, Kovatsch Matthias <[email-masked]> wrote:
> 
> Hi all
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 4 Aug 2017 22:14:56 +0000

> (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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 5 Aug 2017 00:20:55 +0200

> On Aug 5, 2017, at 00:14, Kovatsch Matthias <[email-masked]> wrote:
> 

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

> 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

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 4 Aug 2017 22:45:02 +0000

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

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?

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

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

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 5 Aug 2017 02:12:24 +0200

Klaus Hartke wrote:
> 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

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 5 Aug 2017 01:41:57 +0200

>From [1]:

   For a presented request, a CoAP endpoint MUST NOT use a stored
   response, unless:

   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.

[1] always confuses me a bit though, because it only considers
applicable options to form the cache key, and requires the request
method to match in addition to that. It would have been simpler to
define the cache key to include everything that must match.

[1] does not include the request payload in the cache key, but that
turned out to be likely a bug: If the response depends on the request
payload, then the request payload should really be part of the cache
key. On the other hand, if the response does not depend on the request
payload (e.g., a 4.04 Not Found response), then the request payload
should not be part of the cache key (and, in the case of a 4.04, the
cache key should probably not even include the request method).
However, RFC 7252 does not define any mechanism that tells a cache
what parts of a request a response depends on, so 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.

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.6

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 5 Aug 2017 17:37:35 +0000

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