Fetch method 'Not Allowed'

[Ramzi04]

The output of the command python3 -m aiocoap.cli.defaults is :
Python version: 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0]
aiocoap version: 0.4.1
Modules missing for subsystems:
dtls: missing DTLSSocket
oscore: everything there
linkheader: everything there
prettyprint: everything there
Python platform: linux
Default server transports: oscore:tcpserver:tcpclient:tlsserver:tlsclient:ws:udp6
Selected server transports: oscore:tcpserver:tcpclient:tlsserver:tlsclient:ws:udp6
Default client transports: oscore:tcpclient:tlsclient:ws:udp6
Selected client transports: oscore:tcpclient:tlsclient:ws:udp6
SO_REUSEPORT available (default, selected): True, True

I run as server aiocoap-rd.
Then i run the following command :
aiocoap-client --method FETCH --content-format 40 --payload '' --accept 40 coap://localhost/resource-lookup/?rt=temperature-c

I get this error :
4.05 Method Not Allowed Traceback (most recent call last): File "/home/aiocoap/.local/bin/aiocoap-client", line 8, in <module> sys.exit(sync_main()) File "/home/aiocoap/.local/lib/python3.8/site-packages/aiocoap/cli/client.py", line 361, in sync_main asyncio.get_event_loop().run_until_complete(single_request(args)) File "/usr/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete return future.result() File "/home/aiocoap/.local/lib/python3.8/site-packages/aiocoap/cli/client.py", line 304, in single_request present(response_data, options, file=sys.stderr) File "/home/aiocoap/.local/lib/python3.8/site-packages/aiocoap/cli/client.py", line 123, in present prettyprinted = pretty_print(message) File "/home/aiocoap/.local/lib/python3.8/site-packages/aiocoap/util/prettyprint.py", line 69, in pretty_print parsed = linkformat.link_header.parse(message.payload.decode('utf8')) File "/home/aiocoap/.local/lib/python3.8/site-packages/link_header.py", line 87, in parse raise ParseException("link_header.parse() failed near %s", repr(scanner.buf)) link_header.ParseException: ('link_header.parse() failed near %s', "'Error: Method not allowed!'")

The GET method works fine.

Any help ?

[chrysn]

The RD in general does not have any defined behavior for FETCH requests, and in particular none for application/link-format jequest payloads -- so "Method not allowed" sounds like a sensible response (even though there's a bit more backtrace output than I'd expect to make sense). Note that a FETCH request with an "empty" payload (for content formats where "beign empty" is even a thing) don't necessarily produce the same results as the corresponding GET requests, it takes a defined format and handler for that. Is there any sensible response you would expect?

[Ramzi04]

A appreciate your immediate support 👍

For example if i run this command:
aiocoap-client --method GET coap://localhost/resource-lookup/?rt=temperature-c

I got two resources:
<coap://127.0.0.1:53082/sensors/temp>; rt=temperature-c; secure=1; anchor="coap://127.0.0.1:53082", <coap://127.0.0.1:44501/sensors/temp>; rt=temperature-c; secure=0; anchor="coap://127.0.0.1:44501"

The secure attribute indicates if the sensor is secure or not.
In my case, i want to perform a fetch method to get only the secure temp sensors (secure=1)

[chrysn]

The way provided by RD to query this is: `aiocoap-client --method GET coap://localhost/resource-lookup/?rt=temperature-c&secure=1` More complex queries would require a format for FETCH to be defined (and CoRAL queries would be one way, but they're not specified yet), but for this application, the query syntax is sufficient.

[Ramzi04]

The recommendation provided to me is to send the request parameters in the payload of FETCH method:
payload={secure=1}

Is there a way to perform this using aiocoap FETCH not the GET method ?
For example :
aiocoap-client --method FETCH --payload 'secure=1' coap://localhost/resource-lookup/?rt=temperature-c

Thanks in advance.

[chrysn]

The recommendation provided to me is to send the request parameters in the payload of **FETCH** method: payload={secure=1}

This would be easier to address if we can discuss this at the source of the recommendation. Who issued that?

Is there a way to perform this using aiocoap **FETCH** not the **GET** method ?

Sure one can alter it that way, but then that's using an unspecified extension to the RD which will be highly unlikely to work with any that would be specified (given the payload you mention is not following the content format application/link-format you described).

[Ramzi04]

Actually, the recommendation (suggestion) is issued from a master thesis work ;)

payload={secure=1}

I write this as illustration example only.

Sure one can alter it that way,

How can i alter it using application/link-format and FETCH method ?

[chrysn]

Actually, the recommendation **(suggestion)** is issued from a master thesis work ;)

Could you just point me to the paper? Then we can look at whether that recommendation or suggestion is applicable here.

>payload={secure=1} I write this as illustration example only.

Thing is: As long as it's all about AND-ed properties, the query format is good enough. For more complex queries, a concret FETCH format would need to be specified for a content format.

>Sure one can alter it that way, How can i alter it using **application/link-format** and **FETCH** method ?

First there'd need to be such a FETCH format specificaton. Then, a render_fetch method can be added to the lookup resources at aiocoap/cli/rd.py.

[Ramzi04]

Could you just point me to the paper?

You can find the suggested work in this link

I would to reproduce this work but using aiocoap.

Can i have your email please so i can reach you.

[chrysn]

For the concrete example you gave (rt=foo&secure=1), the RD's facilities are sufficient. When the paper authors summarize the limitations of GET for resource discovery, they're looking at RFC 6690 (discovery at .well-known/core), and there indeed there is a limitation to a single query parameter. The same restriction does not apply to Resource Directory (not even in the version -10 cited there).

I would to reproduce this work but using **aiocoap.**

For the general case, you can reproduce that by altering the RD processor as outlined above. This won't work with the RD as shipped with aiocoap, though, as that limits its features to the RD itself and proposed extensions. The concrete format suggested (but AFAICT not fully spec'd out) in the referenced is not likely to see specification, because the authors have not sought out the IETF, but also because they are trying to overload the format with a completely different syntax (calling the FETCH payload application/link-format even though it doesn't follow the link-format ABNF). If you want to develop this into something that can be a useful FETCH format for RD lookups, that'd be appreciated. I suggest you have a look at how SenML extended its format to support FETCH (RFC8790), and at the recent work around CoRAL for a more efficiently encoded format of links (see <https://tools.ietf.org/html/draft-ietf-core-coral-03>). Also, feel free to drop a mail to ***@***.*** about what you're doing there, as this may attract some cooperation there and also helps getting things into a shape where it can eventually be used in an interoperable fashion.

Can i have your email please so i can reach you.

You *are* already reaching me ;-) My EMail address is in the README file.

[Ramzi04]

Thank you so much.
I appreciate your help.
I will follow your advises very firmly.

Best.

[chrysn]

I'd appreciate it if you could follow up on this with a link to whatever you're working when it becomes public.

[Ramzi04]

I will do my best.