Actually, the HTTP handling is done by the icx-proxy component in the agent-rs repo, which already is open source, so a feature request there is not inappropriate.
Turning POST into an update call is certainly a possibility. I think we have hesitated because maybe not every POST should be an update call? Imagine an image transcoding service – you probably upload the file with POST, but maybe still want the performance of a query call. Also, despite best intentions in the HTTP spec, in practice you might want state modification on GET as well in some cases.
So tying it to the method seems a bit too rigid.
In my prototype, a query call is done first, and but it can tell the proxy to upgrade to an update call, but it’s also not clear if that’s ideal.
If you don’t mind having an URL that is not*.ic0.app, at least for experimentation, you can run a patched icx-proxy on your own infrastructure, and use that. The HTTP handling sits nicely on top of the core IC, instead of being a feature you can’t extract.
This is great news. Since I’m going to do this anyway I’ll probably make a PR and then it can be debated there
In one of my use cases I could possibly run a forked version but it would be a lot neater not to.
My plan was to make the mapping configurable but with some defaults that match the intentions of the HTTP spec.
That way, different instances of the proxy could be configured differently on start up. It could even be as granular as mapping a specific route to a certain call rather than the entire request method.
Could you help me understand how that would work? I thought an update call is the only way to modify state.
That’s what I mean with a image transcoding: You POST a .gif, it returns a .jpg, but doesn’t actually store anything. Not saying it’s a great example for an on-IC-app, but maybe still can serve as an example for a POST call that you want to get query-called.
Re #1: I suggest that your fork uses a different method name (http_update_request). It can have the same implementation, but the system (rightfully) rejects query calls to methods that aren’t marked query.
I’m trying to better understand what this PR does. Will this allow me to send POST/PUT method calls to the IC via HTTP and have them converted into update calls that go to http_request_update? Or is that still a ways off?
Am I correct in saying that http_request only supports GET requests at the moment? Or it handles everything, but if you try to update something it will fail because http_request interface endpoint is a query?
Canisters can handle HTTP requests by providing a http_request function. However, http_request only allows making query calls.
With my PR, canisters can now also provide a function called http_request_update that allows making update calls.
When handling a HTTP request inside of http_request, if it’s necessary to make an update call, http_request can now return a response including the field upgrade with a value of true. This results in http_request_update to be called instead.
Whether any of this happens due to HTTP methods like GET or POST (or other aspects of the request) is left entirely up to the canister. I had originally inferred whether to “upgrade” from query call to update based on the HTTP method but allowing the canister to determine that explicitly is more flexible.