Jim Schaad
2017-08-26 22:31:01 UTC
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
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