Subject: [core] Some clarification on CoAP POST/PUT related to caching

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 9 Nov 2010 14:21:34 +0800

Hi Zach,

I have a small clarification question on CoAP. Can CoAP support caching
for PUT, POST methods? Yesterday your slides mentioned caching only for
GET method.
I would like to know whether current CoAP can support this. A CoAP
device (or HTTP device) can do a POST/PUT to a resource that is cached
in the proxy. I was thinking such mechanism is possible.

Example:
--------------
HTTP client sending a POST to client that is running only CoAP. The
proxy intercepts and updates the resource state or cached resource state
of the client. Then when CoAP device is ready, proxy will do a POST to
the CoAP client. I was thinking such methods were possible with CoAP.

Thanks.

BR,
Mohana

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Tue, 9 Nov 2010 14:47:50 +0800

Hi Carsten, 

Thanks for reply. Please see below.

BR, 
Mohana

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Tuesday, November 09, 2010 2:32 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: Re: [core] Some clarification on CoAP POST/PUT related to
caching
> 
> Mohana,
> 
> HTTP only ever allows caching responses.
> PUT/POST invalidates a cache but never fills the cache from the
request
> body.

CoAP follows the HTTP principles, so such caching is not possible.  Or
perhaps you are saying there is no need for caching of POST/PUT
In the majority of the scenarios where HTTP and CoAP is used. Or does
caching for request body break the RESTful principles? 
> 
> What you are proposing appears to be caching a request body.

Yes, POST will carry message in the request body. I was considering
caching for this request body.

> More generally, you seem to be assuming that the proxy can anticipate
what
> the server will do with the POST.
> 
> I think it would be useful to flesh out your example a bit more, in
particular
> with respect to the use case.

I was thinking if the server is in sleep state, then when the client
does a POST, the proxy can cache this information and send it to server
when it wakes up.
This was the scenario I had in mind. 
> Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Nov 2010 14:31:42 +0800

Mohana,

HTTP only ever allows caching responses.
PUT/POST invalidates a cache but never fills the cache from the request body.

What you are proposing appears to be caching a request body.
More generally, you seem to be assuming that the proxy can anticipate what the server will do with the POST.

I think it would be useful to flesh out your example a bit more, in particular with respect to the use case.

Gruesse, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 9 Nov 2010 10:51:13 +0100

> does a POST, the proxy can cache this information and send it to server

I think you're talking about a gateway here, not a proxy [1].

If a gateway (a.k.a. "big brother" in some cases) knows the sleep
schedule of a server, it's definitely possible that it processes a
POST request on behalf of the sleeping server, and synchronises with
the server as soon as it wakes up. For example, if the POST request
means something like "append" in the context of the specific resource,
then the gateway could collect all such requests into a single request
and forward that to the server when it wakes up.

I wouldn't call this "caching" though, because it happens at the
application layer, not the CoAP layer. The gateway needs to understand
the application-specific semantics of the request to be able to handle
the request in a meaningful way. I don't think we should add a
store-and-forward mechanism to CoAP as found in Message Queues.

Klaus

[1] http://www.ietf.org/mail-archive/web/core/current/msg00862.html