CoAP Proxy Caching: Keep Cache Freshness Separate from Device Reachability

Yes. A proxy can legitimately return a fresh cached CoAP representation while the origin device is unreachable. That response establishes usable cache data under the declared freshness policy; it does not establish that the device answered this particular request.

Qualify three observations separately: the client can reach the proxy, the representation remains fresh, and a recent exchange reached the origin. This procedure covers CoAP-to-CoAP caching under RFC 7252, with an additional Observe-intermediary check from RFC 7641. Pin the proxy and client versions, cache configuration, security arrangement, and resource contract. HTTP cross-proxies and opaque end-to-end protected payloads require additional mapping and visibility review.

1. Establish the actual cache contract

Under RFC 7252, a cacheable response without Max-Age uses a default of 60 seconds. A proxy-generated response must not extend the origin’s freshness lifetime after accounting for time in the cache. Token changes do not change the cache key. See sections 5.6.1, 5.7.1, and 5.10.5.

Consequently, sending a new request with a new Token is not a reliable cache-bypass test. It creates a new exchange but may retrieve the same stored representation. Inspect the documented proxy policy rather than inventing a query parameter whose effect on the origin resource is unknown.

Create a fixture resource with a known value, an explicit Max-Age, an ETag, and an origin-side request counter. The request counter is test instrumentation, not an assumption about every real sensor. Give the proxy a reproducible empty-cache starting state and record the full effective resource identity, including representation-selecting options.

Observation	What it establishes	What it does not establish
Client receives a valid proxy response.	The tested client-to-proxy path returned a response.	The origin was contacted for this request.
Representation is within its permitted freshness lifetime.	The cache contract permits reuse.	A physical sensor acquired a new sample now.
Origin-side trace records the matching request.	The fixture origin received that request.	The deployed device’s entire application is healthy.
Validated source acquisition metadata advances.	The source contract provides evidence of acquisition progress.	All unrelated device functions are operating.

2. Run the fresh-cache, unreachable-origin experiment

1. Start with the fixture origin reachable and the proxy cache empty. Fetch the resource and correlate the client request with proxy and origin logs.
2. Record the response value, ETag, explicit or default Max-Age, and local monotonic receipt times. Do not substitute a UI render timestamp for cache age.
3. Make the origin unavailable inside the isolated fixture while leaving the client-to-proxy path working.
4. Fetch the same representation before expiry, using a new Token. Check whether the proxy serves its cache without an origin request.
5. Repeat while the stored response remains fresh. Confirm that each outgoing Max-Age reflects remaining lifetime rather than restarting the original lifetime.
6. Continue beyond expiry. Observe the refresh attempt and its bounded failure instead of assuming that cached success can continue indefinitely.

For a hypothetical fixture with an original lifetime of 30 seconds, a cache response sent after 7 seconds must not advertise another full 30 seconds. A remaining lifetime no greater than 23 seconds illustrates the intended accounting before additional conservative delay handling. These numbers describe a test setup, not measured device behavior.

RFC 7252 section 5.7.1 requires a proxy whose destination request times out to return 5.04 Gateway Timeout. Distinguish that origin-path failure from a client timeout that never reaches the proxy. If the product keeps displaying the last known value after either event, label it as retained data according to the application policy, rather than presenting it as a fresh successful retrieval.

3. Exercise expiry and validation boundaries

Repeat the fixture once with Max-Age absent and once with an explicit zero. The first case catches clients that accidentally treat an omitted option as zero or infinite lifetime. The second checks the origin’s explicit no-caching intent and the proxy’s handling of immediate staleness.

Then restore the origin with the same representation and perform an ETag validation path supported by the proxy. A 2.03 Valid response contains an ETag and no payload; it updates the stored response’s freshness information according to section 5.9.1.3. The test should prove which stored representation was validated rather than manufacturing an empty new value.

Change the origin representation and ETag in a separate case. Confirm that consumers receive the replacement value and its associated metadata together. Keep representation validation distinct from measurement acquisition: an unchanged representation can be valid without proving that the physical source took a new sample.

4. Check Observe intermediaries by hop

With Observe, the proxy may maintain its own upstream registration and serve several downstream clients. RFC 7641 section 5 makes each hop independent: an intermediary generates its own Observe values and adjusts Max-Age for its local representation’s age. See Observe intermediary requirements.

Instrument both sides of the proxy. Pause upstream notifications while leaving downstream communication available. Verify that downstream activity cannot indefinitely refresh old data without a valid freshness basis. Do not compare the upstream and downstream Observe numbers as though they were a single end-to-end device sample counter.

Keep this test focused on proxy behavior. Notification ordering and wraparound need their own receiver tests; a correct serial-number comparison does not prove the intermediary’s cache-age accounting.

5. Turn the evidence into a product decision

Choose separate display fields or machine-readable states for data usability and origin contact. For example, “cached value usable” can coexist with “origin contact not recently verified.” Define how long a retained value may be displayed, trended, or used by a downstream decision after cache freshness expires. Do not silently substitute zero for unavailable data.

If a current-origin exchange is essential, provide a documented noncacheable resource or a supported proxy policy and test the actual route. Do not assume that an application-level “refresh” button changes protocol cache behavior. Also test authorization boundaries: a cache that serves one authorized client must not leak that representation to another client merely because the URI matches. See RFC 7252 section 11.2 on cache access controls.

A hypothetical dashboard turns its device indicator green whenever any CoAP response arrives. The fixture shows repeated cache hits while the origin is disconnected. The correction is a clearer status contract and verified cache policy, not faster polling. Release with the two-leg trace, expiry observations, validation behavior, and explicit limits on what the health indicator claims.