X-Accept-CDN

Created on 2022-03-17T12:46:25-05:00

Return to the Index

This card can also be read via Gemini.

Problem: Downloading a web page takes time.

Reaction: People are more likely to stop browsing.

Solution: Store content on high speed servers closer to the user to bring ping time down.

Problem: Content delivery servers gain dragnet surveilance power to monitor all other sites a user visits on the same network.

Reaction: People mostly ignore it; some attempts (ex. DecentralEyes) to pre-cache downloads.

Solution: Use a distributed filesystem to retrieve, cache and forward static content (IPFS.)

Problem: Websites have to link somewhere for content and cannot rely on the browser to deliver IPFS fallback with a graceful drop to a CDN.

Reaction: IPFS does not get used as a CDN.

Solution: Add an X-Header ("X-Accept-IPFS") to requests that specify IPFS may be used.

Problem: X-Header is too specific and people whine.

Reaction: X-Header does not get adopted.

Solution: Instead of X-Accept-IPFS, it's just X-Accept-CDN. Can now specify a list of CDN names in order of preference.

Read keywords separated by spaces and if that CDN is mutually acceptable stop processing and return a page with appropriate links pointing to that CDN.

If the CDN is not mutually acceptable then proceed to the next keyword. Repeat until there are no further keywords or one has been found.

The CDN named "ipfs" means that content is returned as a ipfs:// or ipfs:///file-in-directory which the browser handles in some intelligible way.

The CDN named "none" means that no other CDN will be accepted. Stop processing.

If the end of the list is reached: use whatever CDN is available.

Websites that do not respect or understand the header are completely unaffected and act as a server which just doesn't comply with "none."

Probably a lot of bikeshedding to make this an actual spec.