Extending HTTP request handling of ic-frontend-canister (formerly ic-certified-assets)

[paulyoung]

This library has moved from the cdk-rs repo to here, so I wanted to pick up where I left off with trying to serve additional HTTP requests than just assets from a single canister.

I tried a couple of approaches already in building Codebase and wasn't successful. At the moment I have a frontend (assets) canister (xs2jg-4aaaa-aaaam-qayea-cai) for serving the frontend assets and a backend canister (w7uni-tiaaa-aaaam-qaydq-cai) that also responds to HTTP requests for Git operations.

Git clients support the HTTP protocol and it's important to me to have Codebase be compatible with that.

This means I have to expose an unfriendly URL containing the backend canister ID to people who want to do Git operations. There are other related issues that I hope to address with that but for now a good first step would be to have a single canister be the entry point for HTTP requests.

---

I first tried to add the crate as a dependency, and despite some issues that I managed to work around (dfinity/cdk-rs#304) this didn't seem like a good approach; I would be duplicating what the assets canister already does, and wouldn't get the benefit of the existing workflow in dfx for assets canisters and uploads.

---

The second approach I tried seemed to make more sense; keep the frontend canister as-is, and use the backend canister as a proxy:

use ic_certified_assets::rc_bytes::RcBytes;
use ic_certified_assets::types::{HttpRequest, HttpResponse};

async fn http_request_frontend(request: HttpRequest) -> Result<HttpResponse, (RejectionCode, String)> {
    let frontend_canister_id = Principal::from_text("xs2jg-4aaaa-aaaam-qayea-cai").unwrap();
    let result =
        ic_cdk::api::call::call(frontend_canister_id, "http_request", (request,)).await;
    result.map(|(response,)| response)
}

#[query]
fn http_request(_request: HttpRequest) -> HttpResponse {
    // We'd like to route all requests through here so that we can use
    // one canister as the entry point for our app; this allows us to use the
    // same URL for both HTTP and Git requests. However, since we can't make
    // inter-canister query calls we need to upgrade to an update call.
    HttpResponse {
        status_code: 426,
        headers: vec![],
        body: RcBytes::default(),
        streaming_strategy: None,
        upgrade: Some(true),
    }
}

#[update]
async fn http_request_update(request: HttpRequest) -> HttpResponse {
    let result = http_request_frontend(request.clone()).await;

    match result {
        Ok(response) if response.status_code == 200 => response,
        _ => STATE.with(|state_ref| backend::http_request_update(&state_ref.borrow(), request)),
    }
}

I was hoping that something like the above would evolve into the existing backend canister essentially becoming a HTTP router, and that I could then break the current functionality into different canisters.

However, I ran into problems with that (dfinity/cdk-rs#310) because we can't do inter-canister query calls, and the assets canister doesn't support being called via update. I'm also concerned about outstanding calls when trying to upgrade, and had generally planned to use one-way calls for everything.

---

At this point I'm not sure how to proceed but wanted to try and explain my goal and what I've already tried so that we could explore possible solutions. Does anyone have any suggestions?

(Ultimately I'd like people to be able to use the https://codebase.org domain for Git operations too but there some things to figure out there; currently I'm using https://w7uni-tiaaa-aaaam-qaydq-cai.raw.ic0.app because otherwise I get the HTML for the service worker, and some naive attempts to forward https://git.codebase.org there using DNS got my domain flagged for attempted phishing)

cc @domwoe @nomeata @seniorjoinu

[domwoe]

Hey @paulyoung

I'm wondering why the subdomain approach did not work that you mentioned. In general, this seems like a good approach to me.

I'm not sure if the proxy canister approach is a good idea because you'd need to pipe all the data through inter-canister calls. This could get slow and expensive for bigger repositories.

[paulyoung]

@domwoe I described it a little bit here: https://forum.dfinity.org/t/problem-in-custom-domain-to-assets-canister-url/14751/16?u=paulyoung

I think the reason it doesn’t work is TLS. At least, I got complaints about certificates when trying to clone from https://git.codebase.org/paul/hello-world.git

After that my domain name was automatically flagged for phishing.

[paulyoung]

I ended up using the subdomain redirect feature in Firebase for now. I think that works because Firebase has the certificate.

Some info on that here:

https://forum.dfinity.org/t/custom-domains-for-ic0-app-community-consideration/6162/77?u=paulyoung