And it works! If you go to https://y4oop-liaaa-aaaab-qacha-cai.raw.ic0.app/ it loads kinda slowly (yay for consensus) and keeps counting the requests. Probably the canister will disappear after a while. Maybe I should host the demo permanently…
I was thinking of a guaranteed way of calling an update after returning the fast query. I want the client to get the query response quickly, and the I want to record an Incerement of a served asset in an update. I could have the client do it, but it would be hackable. If the service worker did it as part of the protocol it would be cool and allow us to do gated assets.
This feature also begs the question of how the thing actually works. I assume there is some Kind of replay protection built into the protocol and the request has to be signed, so I’m guessing that these http requests are always anon principal. There is no problem processing the http_request_update because it is anon and thus replay is expected. If you wan to prevent replay I guess you have to do it yourself?
If I put a sig in the header that sig is going to need some kind of nonce that I handle in canister or a malicious node could replay it? Or is there something else at work that would prevent that?
That seems doable but with the caveat that once the client making the HTTP request gets a response (the result of the query) it has no way of being informed of the result of the update call (success, failure, etc.)
For use cases like the one you mentioned that might be fine.
I think this whole feature deserves a proper specification. One may even exist somewhere in private. @nomeata might know more.
Yep…that would be fine. There are a whole host of applications that would be facilitated by being able to know that a query was served without having to have the client wait for consensus.
So if I send a transfer function to a token canister and it is rejected due to insufficient funds, a node provider could hold on to that request and resubmit it once I have funds in my account? Is a reject or throw handles differently than if I returned a Result#err?
Are we still talking about http_request and http_request_update?
I was speaking about those specifically and meant that as far I can tell at that layer any incoming request will be handled and it would be up to the application to decide what to do. Given that there’s little documentation on this feature it’s hard to tell so if I’m going to make assumptions I’m assuming the worst for now
I think you’re posing great questions and it would be good to know the answer both in the context of HTTP and outside of it.
Perhaps @diegop can help direct these questions to the right people.
Totally understand the difference and would love clarity. My assumption is that http_request acts differently, but it would be great to have documentation about exactly how differently.
I updated my telegram bot code to use the official HTTP gateway, worked smoothly. So we now have canisters serving Telegram chat bots without any extra infrastructure! Try it:
Maybe I’ll write a separate post later, we’ll see.
Last reply about http_request_update. I think http_request_update is a milestone update. It makes canister’s http request function more possibilities. This allows canister to be used as a serverless, or a cloud database, and many more interesting features. @paulyoung thank you very much for your great contribution, can you message me with your ICP wallet address? I would very much like to pay 1 ICP for you a cup of coffee☕️.