On Fri, 20 Oct 2023, Mark Gaiser via curl-library wrote:
These are just my thoughts.
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!
Ah right, they want different "origins" for web security stuff. If it would use cookies or HTTP auth, certainly curl users would want that as well.
Isn't the domain approach making HTTPS hosting a little complicated since it uses different host names all the time? Basically forcing wildcard certs I suppose.
It also leaks the target hash in the TLS SNI field to network observers for remote HTTPS gateways in a way the path approach does not.
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
"Playing with the thought" does not make it sound like an established standard that is accepted and adopted to a level that makes it suitable for a client like curl to start using it... But maybe that's just your phrasing?
I assume the "we" referred to here is "the IPFS community" ?
However, we're wondering if it would be acceptable for curl to set this header by default for the ipfs/ipns schemes?
Seems harmless and safe enough to me. And if the gateway still wants to redirect, curl users should be used to realizing that and then asking for redirects to be followed.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
