-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it practical to have the GET version altogether? #2
Comments
I was also thinking about getting rid of GET. However, apart from the cross-proxying argument you gave, I also wanted to provide a method for "legacy CoAP" (so a CoAP implementation where FETCH is not implemented). But then again, FETCH-support is relatively easy to deploy on the client side (you literally just need to provide the number for it). Mhh... |
IMHO a URI template processor does not need to have more complexity than say a URI parser (which in some cases we need with CoAP). The one I provided for RIOT takes ~400 bytes of ROM on a Cortex-M0. Once that's there, the question of adding a URI-Query option is just a matter of checking if the |
There haven't been implementer complaints about FETCH in 2019 when
OSCORE was finalized, which indicates that FETCH was indeed simple to
support.
IMHO a URI template processor does not need to have more complexity
than say a URI parser (which in some cases we need with CoAP).
I have hopes that many CoAP clients can do without a URI parser when the
efforts of CoRAL and [CRI](https://datatracker.ietf.org/doc/draft-ietf-core-href/) bear fruit.
The one [I provided for
RIOT](RIOT-OS/RIOT#16702) takes ~400 bytes of
ROM on a Cortex-M0. Once that's there the question of adding a
URI-Query option is just a matter of checking if the `dns` query is
there or not when the URI template is resolved.
That does indeed look like a comprehensive implementation testing for
several of the pitfalls. But it's still 400 byte (and a lot of
code-to-be-maintained), and compatibility dangers from implementers who
don't go all the way but just `s/{?dns}/?dns=$QUERY/` because that's all
they've ever seen -- especially when the alternative is so much easier.
|
Another drawback of GET (as pointed out in the current draft version) is that with it block-wise transfer is not possible with large requests. |
Ok, I think we agree for now that in the long run, we should remove GET and POST. However, at least for version |
Do we have an overview of |
I don't; Francesca and I started preparing a survey, but didn't even finish the requirements. |
oops, ... then we do a brief survey offline. we need an overview, which implementation supports |
If it's a helpful data point: In all the interops and implementation discussions around OSCORE that I can remember (and I've been in many of them), never has any implementer complained about the use of FETCH that'd have kept them from using OSCORE with that library. |
Is that really necessary? As mentioned above, adding |
The only nodes where FETCH is interesting is at proxies that cache. Here an (equally minor) adaptation needs to be made, that the payload of a FETCH request is considered for the cache key. |
hard to follow. will talk offline. |
Regardless, I looked a bit into this, and the data is a bit crushing. Of the 19 implementations I looked into so far, only 6 support FETCH. Granted, most of these implementations haven't received an update in years (many last before the publication of RFC8132), but even some implementations I would call reference implementations such as Erbium (in all its flavors known to me, Contiki, Contiki-NG, and Wakaama) do not support FETCH. 😕 |
All I've found so far on why there's both the GET and the POST version of DoH in HTTP is that GETs are cachable.
In CoAP, we have FETCH, which is just there for cases like this, and does away with both contender's downsides:
The only upside I see of keeping GET/POST over FETCH is that DoC could then be implemented by just cross-proxying to a DoH server, but given that such a proxy is unconstrained, reasonably straightforward to implement on its own and can thus take load off the constrained client, I advocate going all FETCH.
The text was updated successfully, but these errors were encountered: