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

http response header for gateways: alt-svc #468

Closed
SgtPooki opened this issue Mar 16, 2024 · 1 comment
Closed

http response header for gateways: alt-svc #468

SgtPooki opened this issue Mar 16, 2024 · 1 comment
Labels
need/triage Needs initial labeling and prioritization

Comments

@SgtPooki
Copy link
Member

The Alt-Svc HTTP header allows a server to indicate that another network location (the "alternative service") can be treated as authoritative for that origin when making future requests.

Doing so allows new protocol versions to be advertised without affecting in-flight requests, and can also help servers manage traffic. Using an alternative service is not visible to the end user; it does not change the URL or the origin of the request, and does not introduce extra round trips.

- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc

can we use this for informing people of multiaddrs or other providers?

@SgtPooki SgtPooki added the need/triage Needs initial labeling and prioritization label Mar 16, 2024
@lidel
Copy link
Member

lidel commented Mar 27, 2024

Thanks for filling this!

We already track alt-svc in ipfs/in-web-browsers#144, so closing as duplicate, but some thoughts below.

I think the summary from ipfs/in-web-browsers#144 (comment) still holds.

As for multiaddrs, making gateway return PeerIDs in HTTP header does not sound good, because immutable response can be cached forever, and none of Peers are forever. Returning URLs of other gateways is also a way of creating soft-centralization and hot-spots.

Affinity hint around content path, and not content provider, is a bit more future-proof because client can use path affinity hint to find working providers without hardcoding them in response – see #462.

As for having a generic hint that content is on IPFS, we already have two ways: X-Ipfs-Path header and DNSLink TXT record. Introducing additional is possible, but requires good rationale why existing ones do not work for some real world use case.

@lidel lidel closed this as not planned Won't fix, can't repro, duplicate, stale Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

2 participants