I’ve been thinking about this (missing) feature on a couple of ocassions while developing, and now that I’m exploring canister signatures, the same question has come up again.
Why doesn’t the Internet Computer support a concept similar to HTTP headers?
The main motivation would be to avoid bloating method arguments with metadata that could instead be sent automatically at the agent level.
The reason that this doesn’t exist is that it’s not strictly necessary (as you also write: you could just lump the data into the function parameters) and we’ve initially rather focused on what is necessary. But now that the is necessary part is done, if this is really nice to have, let’s discuss.
From a technical perspective, though, it is a lot of work to build. Not because it’s complicated, but rather because it touches many different areas (ingress formats, agents, boundary nodes, http endpoints, support in the canister API for both caller and callee, support of those APIs in the CDKs, message format in inter-canister calls, and so forth). So I am mostly wondering whether the benefit is sufficient to justify a major effort.
Do you have an example where this really has massive benefits?
Thanks for the clarification, I wasn’t aware that implementing something like this would require changes across so many layers. Given that level of complexity, I completely understand why it hasn’t been prioritized and why the focus has been on what’s strictly necessary.
The main benefit I had in mind was the ability to attach common metadata like authorization information for canister signatures or hybrid web2/web3 JWT-based flows automatically across all calls during a user’s session, instead of repeating it in every method signature.
But as you said, the functional need can still be addressed today by including this data in the arguments, so the benefit probably isn’t significant enough to justify such a large implementation effort.
There are also a few ideas floating around bringing the HTTP interface closer to web standards, which @ilbert has been working on. Depending on how we move forward in this direction, such features may or may not be easy to address as part of that effort.
I’m trying to come up with a demo to showcase how canisters can receive and handle authenticated HTTP requests, which will require making some changes to some components of the protocol. More details soon.
In the meantime, you can already take a look at the HTTP Authentication PoC work started by @NathanosDev on the following repo: dfinity/http-auth-poc. In that PoC, clients send authenticated HTTP requests to canisters using HTTP Message Signatures, and we validate signatures at the canister level. This can be too expensive in terms of instructions used, that’s why I’m exploring changes at different layers of the protocol.
I also plan to make a proper announcement/request for feedback about these things in the next weeks, but feel free to try it out and give feedback already!
The main problem we found is that BLS signature verification uses a lot of instructions, and hence a lot of cycles, see Benchmarks. I’m exploring solutions at the protocol level to overcome this issue.
Exciting to see this being picked up, it’s one of the main challenges I’ve come across for web2 applications to integrate with canisters.
Being able to sign http calls similarly to canister calls, would make it possible to expose candid equivalent http apis with e.g. generated OpenAPI docs.
This would omit the need for an SDK in web2 projects, though I assume there would still be some minimal code overhead to sign the http requests (and ideally validate their responses).