This is great. I’ll use this for my http_request lecture for the bootcamp.
It would also probably be worth a bounty to flesh it out to a full file server.
One thing that has occurred to me on reading this is that it may be hard(impossible?) to do this for dynamic http responses. Say you serve a page with a time stamp on it. You wouldn’t be able to provide a certified tree with the content of the page because http_request is a query and you would not be able to update it. For dynamic content I guess we’ll always have to use raw?
Correct, and one of my main criticisms of the whole “certified variables” approach to securing queries. I haven’t given up hope that we get proper, system-provided “certified queries” at some point, where the boundary node aggregates the query response from multiple nodes (multi- or threshold signature). This would allow any query to be used securely (even dynamic ones) without any effort on the canister authors side, actually fulfilling the promise of a tamper-proof, easy to use platform. In fact, I’d argue it should be the default. No more raw!
And I’d bet that such a feature would have been less effort than all the work that went into certified variables across the stack and in terms of education.
Maybe one day - someone observed that it’d be internally needed or at least useful for implementing inter-canister query calls, so I’m not giving up hope.
For your original question, here are your possible next steps
Read up on certified variable (videos and documentation)
Look at rust asset canister for a reference implementation
Decide if you need the performant certified queries ? Queries are performant but are hard to implement in a “secure” fashion. You can fall back to updates if you don’t need the speed.
Relying on raw path to access uncertified queries is relies on a “unintended omission” and will be fixed anytime time and your raw accessed will ALSO start to fail.
Please reach out to the community for implementing queries securely with certificates. Falling back to raw path for insecure access to queries is a anti-pattern and is relies on a behavior which will be fixed anytime in near future.
IMO a lot of important aspects are getting buried under this infamous error code body cannot be verified
Insecurity of non-certified queries
Difficulty in implementing certified response . (This is a known unspoken issue - designing certified queries is orders of magnitude more arduous than coding any other aspect of a IC canister)
confusion around spec of raw/non-raw mandatory non-mandatory aspects of certificate generation and checking. This is the part that can be easily fixed.
I don’t believe throwing boundary nodes into mix brings any clarity to the situation. Boundary nodes should best serve as performance enhancements and not turn into a core requirement/extension for the IC protocol. At least, until they are completely decentralized.