# The "Body does not pass verification" error from a Motoko canister

**URL:** <https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154>\
**Category:** Developers\
**Created:** [February 26, 2022, 5:35pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154 "2022-02-26T17:35:52Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![wewei](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/wewei/32/4486_2.png) [@wewei](https://forum.dfinity.org/u/wewei)\
**Post date:** [February 26, 2022, 5:35pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/1 "2022-02-26T17:35:52Z")

</div>

Hi, Guys  
I’m trying to write a http canister with Motoko. After I deployed it to IC network, I got the “Body does not pass verification” error when I access from browser.  
Canister ID: p5th4-gyaaa-aaaal-qajkq-cai  
URL of problem: [https://p5th4-gyaaa-aaaal-qajkq-cai.ic0.app](https://p5th4-gyaaa-aaaal-qajkq-cai.ic0.app/)  
The RAW URL works fine: [https://p5th4-gyaaa-aaaal-qajkq-cai.raw.ic0.app](https://p5th4-gyaaa-aaaal-qajkq-cai.raw.ic0.app/)  
My code: [TinTinLectures-Lesson3/main.mo at master · wewei/TinTinLectures-Lesson3 (github.com)](https://github.com/wewei/TinTinLectures-Lesson3/blob/master/src/Lesson3/main.mo)

From this topic  
[Service Worker Bug? Body does not pass verification - Developers - Internet Computer Developer Forum (dfinity.org)](https://forum.dfinity.org/t/service-worker-bug-body-does-not-pass-verification/7673/5)

I learned this error has something to do with the service worker. I debugged into the SW, found the response has no `IC-Certificate` header. But I don’t understand why.

Could anybody help me on this? Or, even better, share some document/ post/ sample code about how the http\_request work.

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [February 26, 2022, 8:25pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/2 "2022-02-26T20:25:33Z")

</div>

These articles will have some good info for you:

> [@Service Worker Bug? Body does not pass verification](https://forum.dfinity.org/t/service-worker-bug-body-does-not-pass-verification/7673/11):
>
> The NNS App isn’t using dfx’s dynamic asset canister, but rather has the assets hard-coded in it’s single backend canister, with it’s own implementation of the http\_request interface. And as you can see there, it doesn’t even know about streaming: So how does it handle assets larger than 2MB (if it even does)? Turns out that the maximum response size has been increased multiple times since the asset canister has been created (mostly in response to the NNS canisters themselves growing larger…

> [@Boundary node http response headers](https://forum.dfinity.org/t/boundary-node-http-response-headers/10747/45):
>
> I don’t quite understand the question. The certification needs to build a trust path between something that the user (the service work) knows, namely the IC root key, and the file just loaded. This involves a few steps (root public key → subnet public key → subnet state merkle tree root → subnet state merkle tree entry with certified data from canister → canister merkle tree root → canister merkle tree entry with sha256 of file loaded → file), and one of the steps requires the SHA256 signature o…

I’d love to see a reference implementation of a motoko file server, so please revert if you get it figured out! I think you are going to have to use the certified data api.

---

<div class="post-metadata">

**Author:** ![wewei](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/wewei/32/4486_2.png) [@wewei](https://forum.dfinity.org/u/wewei)\
**Post date:** [February 27, 2022, 1:16am UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/3 "2022-02-27T01:16:23Z")

</div>

Thank you, I’ll read the threads first as well as the `ic-certified-assets` to get more background.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [February 27, 2022, 10:40am UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/4 "2022-02-27T10:40:42Z")

</div>

> [@skilesare](#):
>
> I’d love to see a reference implementation of a motoko file server

Maybe too minimal to count as a “reference implementation”, but [https://github.com/nomeata/motoko-certified-http](https://github.com/nomeata/motoko-certified-http) could be a starting point.

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [February 27, 2022, 7:13pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/5 "2022-02-27T19:13:36Z")

</div>

This is great. I’ll use this for my http\_request lecture for the bootcamp.

It would also probably be worth a bounty to flesh it out to a full file server.

One thing that has occurred to me on reading this is that it may be hard(impossible?) to do this for dynamic http responses. Say you serve a page with a time stamp on it. You wouldn’t be able to provide a certified tree with the content of the page because http\_request is a query and you would not be able to update it. For dynamic content I guess we’ll always have to use raw?

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [February 27, 2022, 8:34pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/6 "2022-02-27T20:34:39Z")

</div>

Correct, and one of my main criticisms of the whole “certified variables” approach to securing queries. I haven’t given up hope that we get proper, system-provided “certified queries” at some point, where the boundary node aggregates the query response from multiple nodes (multi- or threshold signature). This would allow _any_ query to be used securely (even dynamic ones) without _any_ effort on the canister authors side, actually fulfilling the promise of a tamper-proof, easy to use platform. In fact, I’d argue it should be the default. No more `raw`!

And I’d bet that such a feature would have been less effort than all the work that went into certified variables across the stack and in terms of education.

Maybe one day - someone observed that it’d be internally needed or at least useful for implementing inter-canister query calls, so I’m not giving up hope.

---

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [February 27, 2022, 8:42pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/7 "2022-02-27T20:42:21Z")

</div>

> [@skilesare](#):
>
> You wouldn’t be able to provide a certified tree with the content of the page because http\_request is a query and you would not be able to update it

You could use `http_request_update` 🙂

---

<div class="post-metadata">

**Author:** ![faraz.shaikh](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/faraz.shaikh/32/4005_2.png) [@faraz.shaikh](https://forum.dfinity.org/u/faraz.shaikh)\
**Post date:** [February 27, 2022, 10:04pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/8 "2022-02-27T22:04:09Z")

</div>

@wewei

For your original question, here are your possible next steps

1. Read up on certified variable (videos and documentation)
2. Look at rust asset canister for a reference implementation

Decide if you need the performant certified queries ? Queries are performant but are hard to implement in a “secure” fashion. You can fall back to updates if you don’t need the speed.

Relying on raw path to access uncertified queries is relies on a “unintended omission” and will be fixed anytime time and your raw accessed will ALSO start to fail.

Please reach out to the community for implementing queries securely with certificates. Falling back to raw path for insecure access to queries is a anti-pattern and is relies on a behavior which will be fixed anytime in near future.

---

<div class="post-metadata">

**Author:** ![faraz.shaikh](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/faraz.shaikh/32/4005_2.png) [@faraz.shaikh](https://forum.dfinity.org/u/faraz.shaikh)\
**Post date:** [February 27, 2022, 10:14pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/9 "2022-02-27T22:14:46Z")

</div>

IMO a lot of important aspects are getting buried under this infamous error code body cannot be verified

1. Insecurity of non-certified queries
2. Difficulty in implementing certified response . (This is a known unspoken issue - designing certified queries is orders of magnitude more arduous than coding any other aspect of a IC canister)
3. confusion around spec of raw/non-raw mandatory non-mandatory aspects of certificate generation and checking. This is the part that can be easily fixed.

I don’t believe throwing boundary nodes into mix brings any clarity to the situation. Boundary nodes should best serve as performance enhancements and not turn into a core requirement/extension for the IC protocol. At least, until they are completely decentralized.

---

<div class="post-metadata">

**Author:** ![nomeata](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/nomeata/32/733_2.png) [@nomeata](https://forum.dfinity.org/u/nomeata)\
**Post date:** [February 28, 2022, 8:31am UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/10 "2022-02-28T08:31:06Z")

</div>

> [@faraz.shaikh](#):
>
> This is a known unspoken issue

I keep talking about this issue all the time 🙂

(I wish someone at DFINITY would make [this document](https://docs.google.com/document/d/1vwWbCWGJ0n-aGq362gbRev_Apfkh5Mp3Uv4h7Lby24A/view) public, it discusses the issue with certified variables, and might be helpful for anyone digging deeper. But a TL;DR of it is in my post above.)

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [February 28, 2022, 2:15pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/11 "2022-02-28T14:15:45Z")

</div>

I’m still a bit confused as to if this is natively handled or if it only works with the ICX proxy. Will this get hit for any HTTP request that is not a get natively?

My particular use case involves images and having them return in query time is pretty important. Waiting for consensus is going to make the page crawl.

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [February 28, 2022, 2:37pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/12 "2022-02-28T14:37:01Z")

</div>

> [@faraz.shaikh](#):
>
> Relying on raw path to access uncertified queries is relies on a “unintended omission” and will be fixed anytime time and your raw accessed will ALSO start to fail.

Does this mean that raw access will go away in the future?

---

<div class="post-metadata">

**Author:** ![paulyoung](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/paulyoung/32/5251_2.png) [@paulyoung](https://forum.dfinity.org/u/paulyoung)\
**Post date:** [March 2, 2022, 8:39pm UTC](https://forum.dfinity.org/t/the-body-does-not-pass-verification-error-from-a-motoko-canister/11154/13 "2022-03-02T20:39:51Z")

</div>

> [@skilesare](#):
>
> I’m still a bit confused as to if this is natively handled or if it only works with the ICX proxy. Will this get hit for any HTTP request that is not a get natively?

This was the last I heard from @faraz.shaikh:

> [@Feature request: map appropriate HTTP request methods to update calls](https://forum.dfinity.org/t/feature-request-map-appropriate-http-request-methods-to-update-calls/4303/17):
>
> I am fairly certain this hasn’t been rolled out. I checked the update logs and I know for sure about an unrelated issue blocking production upgrades. I will pull the built binary to ic stop gap repo. & update this thread when prod is up. (This week)
