[rust, ic_cdk] gzip canister response

Hey all.

Wondering if there’s any reason that ic_cdk doesn’t support content-encoding out of the box?

I did a little tracking through ic_agent and realize that the only header being set on requests that use the Reqwest transport is the content-type: application/cbor.

I assume maybe it was to much work to get this working between the agent, some proxy engine (nginx?) and the CDK used for the WASM binaries.

It would be nice to be able to specify (we were thinking of doing so at the macro level) that we want some content-encoding (the same we specify a guard function in the canister #[query(content_encoding="gzip")]), that would allow the client side to know that the payload had been encoded by setting the content-encoding header. I assume that some intermediary / proxy takes the canister function responses and wraps them as HTTP responses for the Agent to consume (just curious for my own mental model on how this actually works).

Also curious if there is some obvious pitfall I’m over looking as to why this isn’t in play already?

Thanks for the help =]

Canisters speak in Candid, not Http. So it doesn’t make sense to deal with http headers in CDK.

Let me elaborate the procedure of a call to IC via its HTTP interface.
IC decode the CBOR encoded ingress message (HTTP request), do some certificate check and then pass method call to the target canister. The canister do the actual method call and return. Then IC get the return value and wrap it into a HTTP response.

While, it do makes sense that a canister specialize in handling HTTP communication. There is already an assets canister bundled with dfx. The core of this canister is the http_request method. And you can specify content-type, headers for each asset when call create_asset.

1 Like