Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
IPFS, exploring the option for a default header to make gateway behavior explicit?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mark Gaiser via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 20 Oct 2023 15:15:28 +0200
Disclaimer: These are just my thoughts. I don't work for Protocol Labs
(company behind IPFS) anymore and am in that sense just an IPFS
enthusiastic dev that tries to make it more usable.
Hi,
An IPFS URL passed to a gateway, like this (safe to try, it's big buck
bunny):
ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
Can be translated by the gateway in two ways (path [1] and subdomain [2]).
The path version looks like:
-
http://localhost:8080/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
The subdomain variant looks like:
-
http://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi.ipfs.localhost:8080
The way IPFS gateways currently work by default (configurable in its
settings) is to redirect the path based version to the subdomain based one.
In a web browser context, where IPFS is used most, this all makes perfect
sense!
A consequence of this default is that a curl command like can work and fail:
curl ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
If the gateway curl found is going to redirect then the above will fail and
"-L" (follow redirect) needs to be added to the command.
On the IPFS gateway side of things we're now playing with the thought to
add the ability to make the gateway behavior explicit. For example, we're
thinking of adding a header like:
Ipfs-Gateway-Mode: path | subdomain
If you'd pass the header:
Ipfs-Gateway-Mode: path
Then the gateway would honor this request (no redirect to subdomain) and
give you the data you've requested.
Thus far none of this would require any change in curl.
However, we're wondering if it would be acceptable for curl to set this
header by default for the ipfs/ipns schemes? It changes nothing with regard
to follow redirects. Instead it's a hint to the gateway to not redirect at
all and just give the data back as-requested. Not having to pass this
header in curl is a big win in terms of user friendliness, but it comes at
the cost of implicitly adding a header.
I'm curious how the devs here think about this and if it would be
acceptable?
Best regards,
Mark Gaiser
[1] https://docs.ipfs.tech/how-to/address-ipfs-on-web/#path-gateway
[2] https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway
Date: Fri, 20 Oct 2023 15:15:28 +0200
Disclaimer: These are just my thoughts. I don't work for Protocol Labs
(company behind IPFS) anymore and am in that sense just an IPFS
enthusiastic dev that tries to make it more usable.
Hi,
An IPFS URL passed to a gateway, like this (safe to try, it's big buck
bunny):
ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
Can be translated by the gateway in two ways (path [1] and subdomain [2]).
The path version looks like:
-
http://localhost:8080/ipfs/bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
The subdomain variant looks like:
-
http://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi.ipfs.localhost:8080
The way IPFS gateways currently work by default (configurable in its
settings) is to redirect the path based version to the subdomain based one.
In a web browser context, where IPFS is used most, this all makes perfect
sense!
A consequence of this default is that a curl command like can work and fail:
curl ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi
If the gateway curl found is going to redirect then the above will fail and
"-L" (follow redirect) needs to be added to the command.
On the IPFS gateway side of things we're now playing with the thought to
add the ability to make the gateway behavior explicit. For example, we're
thinking of adding a header like:
Ipfs-Gateway-Mode: path | subdomain
If you'd pass the header:
Ipfs-Gateway-Mode: path
Then the gateway would honor this request (no redirect to subdomain) and
give you the data you've requested.
Thus far none of this would require any change in curl.
However, we're wondering if it would be acceptable for curl to set this
header by default for the ipfs/ipns schemes? It changes nothing with regard
to follow redirects. Instead it's a hint to the gateway to not redirect at
all and just give the data back as-requested. Not having to pass this
header in curl is a big win in terms of user friendliness, but it comes at
the cost of implicitly adding a header.
I'm curious how the devs here think about this and if it would be
acceptable?
Best regards,
Mark Gaiser
[1] https://docs.ipfs.tech/how-to/address-ipfs-on-web/#path-gateway
[2] https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-10-20