Ah this is what I was thinking of

C

Chaika•12/29/23, 1:04 AM

you get query string sorting and origin passthrough for free via cache rules

C

Chaika•12/29/23, 1:04 AM

nice guy cf giving ent stuff lol

UUnsmart Ah this is what I was thinking of

E

Erisa•12/29/23, 1:05 AM

Yuh, the cache rules stuff is basically a pretty UI for those custom cache keys. If you want to go crazy and write a string yourself you can do that in a worker (though its a lot easier to get it wrong and mess up your cache)

D

dave•12/29/23, 1:05 AM

D

dave•12/29/23, 1:05 AM

does this look sane if I want to cache all S3 API requests?

CChaika you get query string sorting and origin passthrough for free via cache rules

E

Erisa•12/29/23, 1:06 AM

And True-Client-IP with transform rules

Ddave Click to see attachment

E

Erisa•12/29/23, 1:06 AM

lgtm

E

Erisa•12/29/23, 1:07 AM

Outbound fetch requests go through cache rules and page rules, it feels weird to write them for external hosts but its powerful

CChaika you get query string sorting and origin passthrough for free via cache rules

D

dave•12/29/23, 1:07 AM

you get status code ttl caching too lol

C

Chaika•12/29/23, 1:08 AM

huh I didn't even realize that was an ent thing

D

dave•12/29/23, 1:08 AM

this confuses me, which one takes priority?

D

dave•12/29/23, 1:08 AM

will it use cache-control if present, and if not, the status code ttl?

U

UnsmartOP•12/29/23, 1:09 AM

I think you need the last option

U

UnsmartOP•12/29/23, 1:09 AM

Although I guess that would be the input right under that’s very confusing

E

Erisa•12/29/23, 1:10 AM

I'm pretty sure status code TTL is an override, using it instead of "use this TTL" is a tad redundant

EErisa I'm pretty sure status code TTL is an override, using it instead of "use this TT...

D

dave•12/29/23, 1:10 AM

I don't want to override non-200s though

Ddave I don't want to override non-200s though

E

Erisa•12/29/23, 1:10 AM

https://up.erisa.uk/firefox_8oxmdgOT2s.png

E

Erisa•12/29/23, 1:11 AM

I think they would have the same effect, this one just makes more sense in my mind

E

Erisa•12/29/23, 1:12 AM

(note that due to the cache-control spec being super weird you have to do no-store and should not pick no-cache)

EErisa (note that due to the cache-control spec being super weird you have to do no-sto...

D

dave•12/29/23, 1:12 AM

yeah that threw me off earlier today too

EErisa https://up.erisa.uk/firefox_8oxmdgOT2s.png

D

dave•12/29/23, 1:14 AM

Ddave what on earth, Backblaze returns a 403 when it can't find a file

D

dave•12/29/23, 1:16 AM

ah, this is probably because I only gave the B2/S3 API key permissions to read and write files, not list files.

Ddave Click to see attachment

E

Erisa•12/29/23, 1:18 AM

Nice, though we dont cache any 1xx by default and I'm pretty sure the TTL override at the top only applies to 200 :P
Either way, good to be explicit like that and its more clear in future what this rule is doing and can be easily adjusted if needed!

D

dave•12/29/23, 1:19 AM

also did this to avoid caching versioned presigned URLs.

E

Erisa•12/29/23, 1:20 AM

Fancy

EErisa Click to see attachment

D

dave•12/29/23, 1:20 AM

is this the same as toggling

no query parameters

no query parameters

no query parameters

no query parameters?

E

Erisa•12/29/23, 1:23 AM

Yes

E

Erisa•12/29/23, 1:23 AM

The top option is that setting off, the bottom is it on, the ones in the middle are fun ent bonuses

D

dave•12/29/23, 1:23 AM

hmm, it doesn't seem to be working :/

D

dave•12/29/23, 1:23 AM

oh wait

D

dave•12/29/23, 1:24 AM

yep, it's working!

D

dave•12/29/23, 1:24 AM

ty!

D

dave•12/29/23, 1:25 AM

How can I lock this down to only cache for my Worker subrequests?

D

dave•12/29/23, 1:28 AM

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId") and cf.worker.upstream_zone in {"aimoda.workers.dev" "ai.moda"}

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId") and cf.worker.upstream_zone in {"aimoda.workers.dev" "ai.moda"}

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId") and cf.worker.upstream_zone in {"aimoda.workers.dev" "ai.moda"}

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId") and cf.worker.upstream_zone in {"aimoda.workers.dev" "ai.moda"}

Can't do this

D

dave•12/29/23, 1:30 AM

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId" and any(http.request.headers["cf-worker"][*] in {"ai.moda" "aimoda.workers.dev"}))

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId" and any(http.request.headers["cf-worker"][*] in {"ai.moda" "aimoda.workers.dev"}))

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId" and any(http.request.headers["cf-worker"][*] in {"ai.moda" "aimoda.workers.dev"}))

(http.request.uri.query contains "X-Amz-Algorithm=AWS4-HMAC-SHA256" and not http.request.uri.query contains "versionId" and any(http.request.headers["cf-worker"][*] in {"ai.moda" "aimoda.workers.dev"}))

D

dave•12/29/23, 1:30 AM

Is this correct?

D

dave•12/29/23, 1:32 AM

that seems to break caching

E

Erisa•12/29/23, 1:32 AM

cf-worker will never work in rules

E

Erisa•12/29/23, 1:32 AM

So dont even try

Ddave How can I lock this down to only cache for my Worker subrequests?

E

Erisa•12/29/23, 1:32 AM

Just add the hostname as well, the only thing that can request a hostname not on your zone through a cache rule is your own workers.
Hostname contains "backblazeb2.com" should be sufficient

EErisa Just add the hostname as well, the only thing that can request a hostname not on...

D

dave•12/29/23, 1:36 AM

I should probably match by full hostname now that I think about it.. isn't there a chance I could shoot myself in the foot by caching something that's not meant to be public?

E

Erisa•12/29/23, 1:36 AM

Maybe, depends on the semantics of your worker I suppose

E

Erisa•12/29/23, 1:37 AM

Rule syntax is pretty flexible, narrow it down as much as youre happy with

EErisa Maybe, depends on the semantics of your worker I suppose

D

dave•12/29/23, 1:38 AM

yeah, after thinking bout this more, I'm definitely gonna stick with limiting it. That way I don't have to be scared about another Worker doing fetch and getting private data

E

Erisa•12/29/23, 1:39 AM

I believe you can even add secret request headers for each worker and then reference those in the rule

D

dave•12/29/23, 1:39 AM

does this impact anything given that we already overrode stuff in the cache key area?

E

Erisa•12/29/23, 1:40 AM

I wouldnt touch it, it will cause origin cache-control to start overriding your settings in unpredictable ways

EErisa I believe you can even add secret request headers for each worker and then refer...

D

dave•12/29/23, 1:40 AM

so do Cache Rules impact only saving cache results, or does it impact both saving and retriving cache results?

Ddave so do Cache Rules impact only saving cache results, or does it impact both savin...

E

Erisa•12/29/23, 1:44 AM

Did a quick test to confirm and it impacts serving as well, if you dont match the rule then you get default cache behaviour instead. e.g. I made a rule to only cache https://erisa.dev/ html if you dont send

x-test: testing

x-test: testing

x-test: testing

x-test: testing and when I send that header I get DYNAMIC even though its HIT without it

EErisa Did a quick test to confirm and it impacts serving as well, if you dont match th...

D

dave•12/29/23, 1:45 AM

nice, thank you! Is there a special header that only a Worker would have, or do I need to maintain my own API-like key?

Similar Threads

Similar Threads

Similar Threads