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:43:14 +0200
On Fri, Oct 20, 2023 at 7:25 PM Mark Gaiser <markg85_at_gmail.com> wrote:
>
>
> 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
>
(ugh, double errors)
I meant:
- On the IPFS side they will update their gateway spec to include this
header
> - 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:43:14 +0200
On Fri, Oct 20, 2023 at 7:25 PM Mark Gaiser <markg85_at_gmail.com> wrote:
>
>
> 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
>
(ugh, double errors)
I meant:
- On the IPFS side they will update their gateway spec to include this
header
> - 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