Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Cache-Control handling for inline CIDs #358

Closed
Winterhuman opened this issue Dec 16, 2022 · 1 comment
Closed

Document Cache-Control handling for inline CIDs #358

Winterhuman opened this issue Dec 16, 2022 · 1 comment
Assignees

Comments

@Winterhuman
Copy link

Winterhuman commented Dec 16, 2022

The spec docs for Cache-Control: only-if-cached (See ipfs/kubo#9082) don't mention how gateways should handle requests with inline CIDs (whether they should be treated as any other CID, or separately to other CIDs).

Right now, gateways respond with a miss on the initial request, but also, they seem to respond with HTTP/2 200 as well? (I'm pretty sure this is affecting newer gateways as I don't think I saw HTTP/2 412 in the Curl requests once)

@Winterhuman Winterhuman added the need/triage Needs initial labeling and prioritization label Dec 16, 2022
@lidel lidel self-assigned this Jan 19, 2023
@lidel lidel added P2 Medium: Good to have, but can wait until someone steps up and removed need/triage Needs initial labeling and prioritization labels Jan 19, 2023
@lidel
Copy link
Member

lidel commented Jan 19, 2023

Identity CID is logically the same state as if block was in local datastore – gateway can respond without doing any p2p.
There is no need to special-case CIDs based on their hash type. The miss you described is explained in ipfs/kubo#9512 (comment)

@lidel lidel closed this as not planned Won't fix, can't repro, duplicate, stale Jan 19, 2023
@lidel lidel removed the P2 Medium: Good to have, but can wait until someone steps up label Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants