http response header for gateways: alt-svc

[SgtPooki]

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?

[lidel]

Thanks for filling this!

We already track alt-svc in https://github.com/ipfs/in-web-browsers/issues/144, so closing as duplicate, but some thoughts below.

I think the summary from https://github.com/ipfs/in-web-browsers/issues/144#issuecomment-1030254667 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.