Subject: [core] Observe on non-GET request

From: Jim Schaad <[email-masked]>
Date: Sat, 26 Aug 2017 15:31:01 -0700

I have now be part of two different situations where the question has arisen
of what happens if one attempts to do an observe on a message which is not a
GET request.  RFC 7641 only talks about what happens if this option is part
of a GET or a response, it does not have any indications about what should
happen if this option occurs on a PUT request operation.

Both of the situations that I have looked at involve security operations
where the response would never be cached by a proxy, so all of the text
dealing with freshness and caching behavior are moot for me.  I would, for
example, always put a Max-Age=0 option in the responses so that caching
would not occur.

I was not involved in the CORE group at the time that observe was being
formulated and discussed, but my assumption is that all of the discussions
were dealing with the cases of wanting to cache responses to gets so that
network traffic could be reduced and they did not ever look at the types of
cases that I am currently playing with.  I can do a single get operation to
setup the observe relationship for one of the cases which will basically
return an empty response but setup the observe relationship on all of the
servers and proxies. No association of queries and responses can be done for
these as all observes would be using the same token value. In the other
case, since the observe could be assumed to be on a get it would not hide
the fact that this is a get relation and that responses are tied to this
specific request (based on the token).

So I guess the questions are:

1. What should happen to an observe on a PUT?
2. Should we re-visit this question and see if we want to change the
behavior?

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 27 Aug 2017 00:44:05 +0200

> 1. What should happen to an observe on a PUT?

The Observe option is not defined for PUT and is therefore treated as
an unrecognized option [1].

> 2. Should we re-visit this question and see if we want to change the

What would an Observe option in a PUT request mean? For example, an
Observe option in a GET request gives you a continuously updated
representation of a resource. Would an Observe option in a PUT request
give you a continuously updated action result?

The same effect of an Observe option in a GET request can be achieved
by repeatedly making normal GET requests ("polling"). How could the
same effect of an Observe option in a PUT request be achieved with
normal PUT requests?

Klaus

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

---

From: Jim Schaad <[email-masked]>
Date: Sat, 26 Aug 2017 18:12:42 -0700

> -----Original Message-----
> From: Klaus Hartke [mailto:[email-masked]]
> Sent: Saturday, August 26, 2017 3:44 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked] WG <[email-masked]>
> Subject: Re: [core] Observe on non-GET request
> 
> Jim Schaad wrote:
> The Observe option is not defined for PUT and is therefore treated as an
> unrecognized option [1].

Would probably be nice to make that explicit in the Observe RFC if it gets revised.

> representation of a resource. Would an Observe option in a PUT request give
> you a continuously updated action result?
> 
> The same effect of an Observe option in a GET request can be achieved by
> repeatedly making normal GET requests ("polling"). How could the same effect
> of an Observe option in a PUT request be achieved with normal PUT requests?

I would want to define the behavior as the same as making a GET on the request for all subsequent requests.  This is basically an optimization to avoid having to do the extra get operation.

Jim