On Fri, Oct 20, 2023 at 7:25 PM Mark Gaiser <mark...@gmail.com> wrote:
> > > On Fri, Oct 20, 2023 at 6:54 PM Daniel Stenberg <dan...@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.html
