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

gateways: document Content-Location #471

Merged
merged 6 commits into from
Apr 18, 2024
Merged

gateways: document Content-Location #471

merged 6 commits into from
Apr 18, 2024

Conversation

hacdias
Copy link
Member

@hacdias hacdias commented Apr 17, 2024

Document Content-Location as part of the work in ipfs/boxo#603.

Context: ipfs/boxo#606

This is duplicated content, but is harmless, and having it here will
save everyone a lot of headache debugging weird HTTP caching setups.
Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm, thank you for documenting this.

Added some additional content, if looks good, feel free to merge.
(no IPIP as this is documenting/filling spec gaps, and not changing existing specs)

Comment on lines +245 to +253
A Client SHOULD include the `format` query parameter in the request URL, in
addition to the `Accept` header. This provides the best interoperability and
ensures consistent HTTP cache behavior across various gateway implementations.

A Gateway SHOULD include the
[`Content-Location`](#content-location-response-header) header in the response when:
- the request contains an `Accept` header specifying a well-known response
format, but the URL does not include the `format` query parameter
- the `format` parameter is present, but does not match the format from `Accept`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hacdias I've added these clarifications as SHOULDs, the goal here is to push everyone towards including explicit ?format in requests – haves a lot of headache in debugging interop/caching problems.

We've always been doing this internally (including both format and Accept), this writes it down as suggested practice.

Copy link
Contributor

@aschmahmann aschmahmann Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it problematic then that some information in accept headers cannot be expressed in the format parameters (e.g. dfs, duplicates and version for CARs)

Copy link
Member

@lidel lidel Apr 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially, could cause issues at some point in the future when a single gateway supports something more than "the Kubo default" and clients actually request non-default CAR variant, including custom implementations with edge cases like #431.

That is why, to avoid cache override problems in the future, we revised position on these, add car-* URL params in #472. This allows us to explicitly list them in Content-Location when non-default CAR was requested (code for rainbow in ipfs/boxo#603)

gateway: car-* request query parameters
@hacdias hacdias merged commit e4e5754 into main Apr 18, 2024
2 of 3 checks passed
@hacdias hacdias deleted the gateway-content-location branch April 18, 2024 05:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: 🎉 Done
Development

Successfully merging this pull request may close these issues.

3 participants