gateway: use regular cache-control for CARs #295
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR removes special-casing of CAR responses,
and makes them follow the same
Cache-Control
rules as raw blocks and regular files:Rationale
This fix already landed in ipfs/kubo#9080 and will be released in kubo 0.14-rc1.
The initial draft used
Cache-Control: no-cache, no-transform
for CARs as a precaution, as desired behavior and response "determinism" was unclear.After talking with gateway operators, and folks who push CARs over HTTP the feedback was unanimous: caching CARs the same way regular files/blocks already are is better.
Handling partial CAR responses
Regular HTTP practices apply: a client can easily detect partial DAG and fetch missing parts in new requests, or retry the original one with
Cache-Control: no-cache
.Handling undefined block order
With regard to "block order" in a CAR, I believe it is already covered by use of weak Etag for CARs:
We are still disabling range requests if block order is not deterministic:
With these, there is no need to disable HTTP caching, as CARs will be logically equivalent, and reusing cached response is beneficial.
cc @gmasgras @thattommyhall @thibmeu @ribasushi @mikeal (just FYI, no need to respond, I believe we want to maximize HTTP caching of CAR responses, but lmk if any concerns)