I’m trying to generate a properly encoded response for the http-request system API from scratch. However, I’m running into the Body does not pass verification error.
I can query the endpoint using the Candid UI which returns:
I’m testing this locally using dfx, but if I calculate the root hash for the tree in IC-Certificate it matches the certified_data hash in certificate['tree']. The sha256 hash of the body also matches the tree['/index.html'] hash. The public key, signature, and message when passed to the bls implementation used by agent-js also passes, and the body properly gzip decompresses to the expected HTML.
Is the “Body does not pass verification” error produced by some portion of the HTTP gateway that’s not open sourced? I’m having trouble figuring what else might be wrong with this response. If I remove the IC-Certificate header, it works as expected since it’s not being certified in that case.
The path ["http_assets", <url>] exists in the tree and is a leaf with a value, where <url> is the utf8-encoded URL from the HttpRequest.
But you say
Should it be tree['http_assets', '/index.html'] instead?
@NathanosDev, please correct me if I’m wrong, but the boundary nodes use the ic-response-verification crate that you can also see in use in the tests I linked above and nothing else (at least for the Body does not pass verification part).
I second this. Making some automation tests will make your life much, much easier when debugging this stuff. Using the ic-response-verification crate directly allows you to extract the exact error that is being emitted and that can help track down the source of any issues.
This seems to be the case in the tree provided by the IC-Certificate header in his example.
Yep, I’d really recommend this approach.
There’s no part of the HTTP Gateway that’s not open sourced. Everything related to the verification of responses can be found here.
Does the leaf at ['http_asset', '/index.html'] match sha256 of the encoded or decoded body? For v1, it should be the hash of the decoded body.
It matches based on the decoded body. Good point though, I did run into that issue previously.
Any idea where that exact error message originates from? I was trying to trace if it might be caused by something other than the actual body certification/verification.
Good to know I’m looking at the right code at least though. I’ll keep digging.
It’s definitely a certification issue, please write a test and use ic-response-verification (Rust) or @dfinity/response-verification (JavaScript) directly so you can observe the original error.