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: Mark Gaiser via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 20 Oct 2023 19:25:32 +0200
On Fri, Oct 20, 2023 at 6:54 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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?
>
Right now it's a thought shared with a couple developers that do work on
this code as a daily job.
That's what the "we" to refers too, sorry for not providing context on that
before.
It's a thought in the sense that they are willing to add it if it makes
sense and if it's going to be used.
Adding it without an application using it makes it a feature that has no
real benefit as passing -L is shorter and works equally well from a user
point of view.
The process would go as follows.
If curl is OK in having this header set be default (for IPFS/IPNS) then:
- On the IPFS they will update their gateway spec to include this flag
- Implement it in the reference gateway implementation
- Implement it in curl
>
> 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.
>
That's great! Thank you for sharing your thoughts on that.
I will get the ball rolling on the IPFS side.
Once their gateway spec is updated, i'll make a PR on curl for adopting it.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
>
Date: Fri, 20 Oct 2023 19:25:32 +0200
On Fri, Oct 20, 2023 at 6:54 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> 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?
>
Right now it's a thought shared with a couple developers that do work on
this code as a daily job.
That's what the "we" to refers too, sorry for not providing context on that
before.
It's a thought in the sense that they are willing to add it if it makes
sense and if it's going to be used.
Adding it without an application using it makes it a feature that has no
real benefit as passing -L is shorter and works equally well from a user
point of view.
The process would go as follows.
If curl is OK in having this header set be default (for IPFS/IPNS) then:
- On the IPFS they will update their gateway spec to include this flag
- Implement it in the reference gateway implementation
- Implement it in curl
>
> 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.
>
That's great! Thank you for sharing your thoughts on that.
I will get the ball rolling on the IPFS side.
Once their gateway spec is updated, i'll make a PR on curl for adopting it.
>
> --
>
> / 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