Open willscott opened 1 year ago
There's actually another wringle here that's going to be tricky.
The request from the [nginx caching]->[l1 shim] is for a slice of a car file (http byte range)
While the request from [l1 shim]->[lassie] only will support entity-bytes
for selecting blocks from a car file.
that translation is not something we have code for, and i wonder if it is complexity we want the shim to have to handle. if we don't we'd need different backing cache objects for the different chunks of origin-fetched files, and will need to think more about how we manage the saturn cache strategy.
Hm.. it this gets too hairy (and it already pretty hairy), may be worth considering if it is less/equal amount of glue code if cache is built around blocks, and not HTTP responses.
If the nginx module always stored individual blocks, and assembled CARs and CAR-slices on the fly based on some index, CAR and fallback block requests would share the same block cache, and we would remove DoS surface that comes from CARs that have duplicate blocks, or storing same blocks multiple times due to different CAR flavours.
I think i agree that it's worth considering. I'm pretty reluctant to support that scope for a first iteration of rhea to launch because it will take a very substantial effort and complexity to get a cache that performs at the level of nginx.
The current translation looks like
We should have the
nginx caching
layer include a directive likeThis will update the sequence to look like:
There are 3 things needed for this to land:
slice
directive in nginxbytes
argument in l1 shim