Can we somehow achieve or build a canister with a interface bahaving like a classic web server

:Gratitude for the clarification. I comprehend the need for the system message size limit, so now my question is with your statement here:

so this chunking in the HTTP Gateway is a great way to avoid issues here.

Where is the chunking happening in the specific? is it in the dfx tool? where the dfx tool uploads asset files in chunks to the asset canister?

Or is the chunking happening on the ic system level of some sort? if so can you laborate on where exactly the request is being chunked and how those chunks are sent? is it the “edge nodes” that are doing the chunking?

Does it work backwards too? if i need to respond to a http request with a large file will the system automatically chunk it for me? lets say the file is stored on my canister as bytes, if the whole file is 50mb, lets say a user requests the file with a public function update call, should the public function on the canister return with the whole mount of the bytes? or would i need to implement chunking on the canister?

Also if the chunking is on the edge nodes for the http_requests, does the chunking also work when communicating with the system through the standard ic api as is stated in the internet-computer-specification? or would the chunking only work when using the http edge node gateway?

The dfx SDK is able to chunk requests and send them to an asset canister. That canister is programmed to receive chunked files and to respond to http_request calls with chunked responses.

You could implement the same functionality in your own canister, but it won’t be present on all canisters, just the one that we build for you when you designate "type": "asset" for that canister in dfx.json.

Even better news - this code is open source! The code to upload chunked assets lives in ic-agent and the http_request interface lives in ic-utils/src/interfaces/http_request.rs.

3 Likes

The canister would have to implement chunking, but hopefully and eventually your CDK will provide a convenient high-level interface for that.

Yes, this chunking we are talking about is a feature of the upcoming HTTP gateway.

4 Likes

This is the best news thank you, good-portunity for the learn of the rust, i am looking for as close to metal as possible here thanks.

1 Like

In agent-rs, all requests to canisters implementing the HTTP interface are converted to query calls:

It seems like it should be trivial to inspect the request method and convert POST/PUT/DELETE/etc to an update call instead, but I’m assuming this code is only for development purposes and won’t affect the HTTP gateway on the network.

I took a look at dfn_http but I haven’t been able to figure out how/where that’s used or intended to be used.

I would contact the author but everything appears as dfinity-bot. It would be helpful if the commits showed the author as well as the committer.

@nomeata, do you know if update calls work with the HTTP interface for canisters?

Perhaps better for another thread, but I’d love some help understanding the process (in general) for proposing a change of this nature.

Is the ic repo a read-only public mirror, or does it accept pull requests?

How does the NNS fit in?

Thanks

I am facing a error when dfx deploy, do you know what cause the error.

ERROR in ic:canisters/supplier
Module build failed: UnhandledSchemeError: Reading from “ic:canisters/supplier” is not handled by plugins (Unhandled scheme).
Webpack supports “data:” and “file:” URIs by default.
You may need an additional plugin to handle “ic:” URIs.

The ic: URI is replaced with dfx-generated/. See the doc here: Add front-end assets :: Internet Computer

I think http_request only supports query method for now. We will need replica support to send update calls inside a query method.

@chenyan thanks Yan!

I would also like to propose that http_request can determine the HTTP status code as part of its return value.

I’ve already encountered a scenario where I need to return a 403 but am unable to do so.

Is there a better place to discuss this and make these proposals?

You can submit an issue at the agent-rs repo.

For update calls, @nomeata has a PoC here: GitHub - nomeata/ic-http-lambda: A HTTP-to-IC bridge (proof of concept)

I think these are both feature requests for the replica though.

Does this mean that an OTP service (provided by a vendor who is not on IC) cannot be deployed via a website served by a canister? Also, is an OTP-like service available on IC?

(removed, moved to Feature request: map appropriate HTTP request methods to update calls - #2 by nomeata)