Feature request: map appropriate HTTP request methods to update calls

Developers
#38

I did a quick test with the Motoko playground:

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…

6 Likes
#39

Thanks for the example! This is huge! Quick question, is there a way to pass in authentication headers so that message.caller set?

#40

Something like return_and_upgrade would be great for tracking statistics.

#41

I’m pretty sure you can set whatever headers you like and check for them in either of the http request functions.

#42

Both http functions already return a HttpResponse. Is that not sufficient?

#43

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.

Access query/http_request logs from a canister
#44

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?

#45

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.

1 Like
Access query/http_request logs from a canister
#46

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.

Decentralized AdWords.

#47

I encourage you not to make such assumptions :slightly_smiling_face:

As far as I can tell none of the above is true.

#48

:face_with_monocle: 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?

Is that how send_dfx?

#49

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 :slightly_smiling_face:

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.

#50

I could try to answer them, but preferably on a dedicated thread :slight_smile:

1 Like
#51

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.

#52

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.

4 Likes
#53

thanks a lot, it worked, i forgot to add upgrade: Bool; to HttpResponse

#54

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☕️.

1 Like
#55

Relevant: Show-and-tell: A Telegram bot on the Internet Computer - #5 by skilesare

1 Like
#56

Thank you for your generosity, but that’s not necessary.

Please build something and use it for cycles instead :slightly_smiling_face:

2 Likes
#57

Yeah, I just verified… seems like http_request is called with the anonymous Principal.