My understanding right now is that if a developer chooses to expose canister functionality through http_request and http_request_update, that they essentially forgo all certification.
It would be great if some kind of certification information could be returned in response headers so that http clients could verify http requests if developers choose not to use the agent.
If certification is really important, then a REST-based paradigm is going to require an easy way to do this, and http response headers seem the obvious way to do this.
The reason rest based services are such an issue is that they are typically unbounded in variability and there is no way to certify all possible responses. We need to consider atomic level certifications such that each item in a json response can provide its certificate. This will explode data sizes though as each data atom will have a merkle witness.
When I was doing the farcaster frame in Motoko it seemed like http_request query calls you could add a cert header, if you ran in through http_request_update first, then cached it. And the http_request_update should run through consensus and create it for you, but I have only played with it a little bit
Late to the party but I have a follow up question.
Consider a canister that update http queries to http updates. How can we have 100% certainty that we went through consensus? The node that received the query could very well have intercepted the call and returned some locally-generated results without going for consensus. Is this understanding correct or am I missing something!?
If the subnet signs it with is key, it has to go through consensus. These signed responses can either come from a update call OR a query call that has the static http response+signature cached
A query call canāt do that on is own, but the first time itās called (assuming itās static content), the request can be upgraded, then stored/cached for other query calls
To be clear a query call can return HTML on its own, but not signed. Also the boundary nodes validate the response bodies for signatures and reject them if invalid, unless you use the ārawā version of the url
Thanks. Iād like to understand how http update calls are implemented. Is it correct that from the outside (client), http query and update calls are similar. When the http calls hits the IC, it is first handled by a single node. And only if it is an update calls more nodes will be involved for consensus.
Feel free to share a link to the docs as well (couldnāt find that info but I may not have looked at the right place).
The client handles them differently through the boundary nodes. With a query call, its just a call to one replica through the node, but the update calls are a call with read_state polling. But the result is essentially the same.
Im not sure on the specifics of how the boundary nodes handle calling multiple replicas but there is some documentation in the wiki
If the initial request returns upgrade = Option<true>, the system will āupgradeā the query into a call, and will use the http_request_update method. You can use that method to do your work, calculate a certificate, and cache the response as well as the certificate. This is the pattern that I call a ācertified cacheā, and is the core of Mops ā¢ Motoko Package Manager. Any CDK can follow this strategy to support certified queries