Add more surrogate-keys

[tripodsan]

Currently only the pipeline sets the surrogate-key based on the resource that is fetched. but the files service by helix-static or directly from the github content don't have one.

this is problematic, if one wants to invalidate the cache based on changes to the content or code repository. especially if resources are requested with additional params or headers, it is not easy to anticipate all possible external variations.

Suggest

• for sources fechted directly from github, fastly should add the has of the raw github url as surrogate-key, similar to helix-pipeline

• for sources fetched via helix-static, helix-static should add the surrogate-keys

• for better support of a purge-all for helix-pages, the current request.host should also be added as surrogate-key.

---

• Support cache invalidation / purge helix-pages#17

[tripodsan]

• for better support of a purge-all for helix-pages, the current request.host should also be added as surrogate-key.

I don't think this is needed anymore...

so I think for helix-publish, we should only add the keys for for sources fechted directly from github.

the only problem is see is, that the sha256+base64 is not available in fastly.

sha256 returns a hex-encoded string.
maybe it's possible to use hmac_sha256_base with a key so that it yields the same result.

[tripodsan]

maybe it's possible to use hmac_sha256_base with a key so that it yields the same result.

no, I just tested it in fastly-fiddle:

set resp.http.x-test = digest.hmac_sha256_base64("", "input");

fails to set any response. using this works:

declare local var.hash_sha256 STRING;
set var.hash_sha256 = digest.hash_sha256("input");
set resp.http.x-test1 = digest.base64(var.hash_sha256);

but it computes the base64 of the hex representation of the sha, which is not what we want.

[tripodsan]

we could use the digest.hmac_sha256_base64() in helix-pipeline as well, with a dummy key, like helix :-)

@trieloff WDYT?

[tripodsan]

closing as outdated.