observe cancellation sends different events
chrysn opened this issue · comments
when a particular block size is pre-selected, copper sends observation requests with an Observe (=0), an Uri-Path and a Block2 option, but the cancellation message only with Observe (=1) and Uri-Path.
this is in conflict with draft-ietf-core-observe-16 3.6, which says about eager cancellation of an observation: "which has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister). All other options MUST be identical to those in the registration request, except for the set of ETag Options". please consider saving the original request in order to satisfy the draft's requirements.
the issue can be worked around by setting "Block late negotiation".
the same issue also shows up when the debug option Uri-Host is set; in that case, i don't see any workaround.
Yes, these updates still need to be included. Feel free to provide pull-requests ;)
Another question is what actual problem you run into at the moment. Hosting environments and unforeseen options will be a problem, but otherwise I cannot see technical difficulties at the server side at the moment. Do you have input on that? (It would be good to identify the affected options.)
On Fri, Feb 13, 2015 at 06:50:39AM -0800, Matthias Kovatsch wrote:
Another question is what actual problem you run into at the moment.
Hosting environments and unforeseen options will be a problem, but
otherwise I cannot see technical difficulties at the server side at
the moment. Do you have input on that? (It would be good to identify
the affected options.)
i'm running into it as of developing the aiocoap library, which
ships a proxy (both forward and reverse) with observation support.
the issue is that i match the incoming requests by their cache-key
(only dropping the observe option). if a client now subscribed with a
block option but tries to unsubscribe without it, it appears to the
server like an unsubscription request that does not match any active
observation; it reacts (correctly in my opition) with a Bad Option
response -- not because it does not recognize the client's subscription
(which gets cancelled properly as it is matched by endpoint and token),
but because the proxy has no representation of the resource requested in
the unsubscription message.
(if the proxy were configured to deal with blockwise transfers, the
block option should be stripped out before calculating the cache-key,
but it seems practical to me to have the proxy running without blockwise
support by default).
does this make sense to you?
Yes, I can see the issues in proxies and they are also the rational behind the requirement in -observe. There is no question we need to fix this in Copper.
From your description, I guess it would be more robust to better separate token matching (used for the cancellation) from the cache lookups. For observe, you need to provide the full repesentation in your cache anyway (as a whole or all blocks), since the client is likely to fetch the other blocks after a notification (which is always only block no. 0). I do not think we actually have a consensus or best practices how to deal with blockwise transfers in caches. In Californium I would go (proxy development is currently on hold...) for always caching the whole response. This also allows also answering to larger block sizes.
in aiocoap, token matching and cache lookups are completely separated -- but the issue still surfaces, because the cancellation information affects the established observation (whose destruction is even withheld long enough so the original request could still be answered from it), but the cache-key that's looked up for request satisfaction was never queried.
as far as blockwise is concerned, the default aiocoap proxy does not do real caching, only for observations (where it has to cache lest to send "still interested" requests on every new incoming subscription).
I fixed it now in such a way that all debug options and the Block option are also added to the proactive cancellation.
Since it is (in my opinion) not a good practice to evaluate these option on the server side for cancellation, one can still alter the debug options before cancellation to test server robustness.