I think I need a bit of a “dummies guide”
Yes, certification v2 is incredibly complex.
I do have plans to create some “dummies” guides. At the moment all we have is the the spec, which is very technical and not very friendly for developers.
My current priority is getting rid of the service worker, and then I’ll be working on Rust libraries to provide support for canisters that need to use this certification outside of the SDK’s asset canister. In theory, most developers shouldn’t need much documentation outside of how to use those libraries.
I can’t say if we’ll also build a Motoko version of these libraries. It’s definitely something I’d be personally interested in working on, but if not I’d be more than happy to help out anyone who would like to create the Motoko counterpart of these libraries.
With these libraries out in the wild, I’ll switch focus to documentation, user guides, and all that good stuff.
The certifying of headers is super strange to me.
Not all headers need or even should be certified. In general, you only need to certify headers that can affect browser or application behavior.
Does that mean that I need to think at the time of asset upload(or generation) about what RESPONSE headers I’m going to send?
Yes, but if you’re only certifying headers that affect browser behavior then you should know these ahead of time anyway. Things like CORS, caching (incl ETAG), content-encoding, and content type. Are there any scenarios that you’re concerned about deciding these headers ahead of time?
Do I put them in a separate place?
I’m not sure if I understand exactly what you mean. You are free to store any known headers however you like, but I would store them in a similar way to your assets. In terms of the hash of those headers, that doesn’t need to be stored, only the hash of the whole response.
Do I need to predict my users request headers?
Only request headers that will cause changes in your certified response headers or body need to be certified. If the value of a request header will not have any meaningful change in your response then there’s no need to certify it. I think it should be feasible to think of these ahead of time since you will have decided on your body and response headers and how they may be affected by request headers beforehand anyway since these changes will need to be coded into your canister.
does that mean I could certify my assets to only be served if the request has a google chrome browser tag in the browser header?
You can do that if you like 
What would be the use case for a request validation that can be predicted?
Some scenarios where this may be applicable are changing the language/encoding of your response or ETAG-based caching. Otherwise, there’s no need to certify request headers.
I’m kind of at a loss at where to start to modify it to get the headers in with the data as well
This is unfortunately difficult to answer in a short forum response. I will provide better documentation on this at some point in the future, but in the meantime, I’d be happy to get in touch directly and try to work through the missing pieces.
Do I just dump the above out in text and it tells the service worker what headers to validate and what headers not to validate?
Yes, that’s exactly what it does. We can look at some examples:
This CEL expression will tell the service worker to skip certification for this response:
default_certification (
ValidationArgs {
no_certification: Empty { }
}
)
This one will tell the service worker to skip certification for the request, and certify the response but only include the Cache-Control header.
default_certification (
ValidationArgs {
certification: Certification {
no_request_certification: Empty {},
response_certification: ResponseCertification {
certified_response_headers: ResponseHeaderList {
headers: ["Cache-Control"]
}
}
}
}
)
This one will tell the service worker to only certify the Cache-Control request header, as well as the q query param, along with the Cache-Control response header:
default_certification (
ValidationArgs {
certification: Certification {
request_certification: RequestCertification {
certified_request_headers: ["Cache-Control"],
certified_query_parameters: ["q"]
},
response_certification: ResponseCertification {
certified_response_headers: ResponseHeaderList {
headers: ["Cache-Control"]
}
}
}
}
)
It also looks like I have to certify that expression as well for every page?
Yes. For every URL you need to decide on your CEL expression, hash the CEL expression, hash the request (implementation example), hash the response (implementation example) and then arrange those hashes into the tree under the corresponding path.
I hope this helps clear up some of the confusion. Feel free to DM me if you’d like to set something up to discuss the development of the Motoko library.