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.
Re: 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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 20 Oct 2023 18:54:24 +0200 (CEST)
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.
Date: Fri, 20 Oct 2023 18:54:24 +0200 (CEST)
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.htmlReceived on 2023-10-20