CID header in HTTP servers responses to HEAD requests

Hey, i was given an http link for downloading a big file and was thinking if it is possible to find the file in IPFS, but for this i need to know the CID without downloading the full file. So i wonder if anyone thought about this already and maybe something was discussed and/or done in this direction.

The idea is to have a CID header in HTTP servers responses to HEAD requests. So any user can get the CID and check if the content is available via IPFS. The task seems quite simple to me: to implement CID calculation for served static files in major HTTP servers (apache, nginx, caddy, etc) and add the header for those responses. Of course, there is no need in this for dynamic data, so the servers just omit the calculation and the header.

There is a proposal with the Alt-Svc specification, but we are a long way from there. Tor Browser just started a similar mechanism to learn an onion address of a website when connecting over regular HTTPS. We could do the same to learn the IPFS CID.

Implementing it in the servers will only be the first part of it, though. There is no way the extra calculation of computing IPFS CIDs will be on by default, so it will remain opt-in, for servers (or maybe on demand?). So the second challenge will be adoption. But with compelling use cases, some specific services may make the shift.

Also, to make use of that, browsers will have to know how to handle the response and fetch the content via IPFS.

The related GH issue:

Tor project’s announcement: https://blog.torproject.org/new-release-tor-browser-95

@shoce you can do something like this by using IPFS Companion. For example, if you go to libp2p.io it will take you to the libp2p website. However, if you view that page using the IPFS Companion extension to Chrome/Firefox (or the one built into Brave) it will detect that the website supports IPFS and instead load it via IPFS.

A few of the options for how IPFS Companion detects a website “supports IPFS” are described in the linked Github page above.

Thanks everyone for replies. I see the point. But it seems to me i mean much much simpler thing. I am about only to add this extra information on the cid of the static content served by http servers into server HEAD reaponse. That’s it. I understand it is better to see the whole set of possibilities and use cases and future improvements but in this case i just mean i want a simple thing: to get a cid of the content served by a http server. This server does not need to support ipfs protocols in any way. Nothing special. Just calculate cid and add to header information so the user can have a clue about the content.

I am about only to add this extra information on the cid of the static content served by http servers into server HEAD reaponse. That’s it.

@shoce How different is that from using the x-ipfs-path header?

Edit: I guess if people are using x-ipfs-path to decide to use IPFS to find the data and you DO NOT plan on actually making the data available over IPFS (whether on that server or any other location) then in order to not cause problems for things like ipfs-companion you probably want your own header.

However, I’m not sure I understand what the point is for adding a CID header to data that people are unable to download as a DAG. In particular, if you’re assuming that someone can do curl test.tld | ipfs add and get the same CID out the other side you should know that that’s only true if you’re both using the same settings (e.g. chunking parameters)