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: Implementing IPFS support in cURL
- 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: Thu, 24 Mar 2022 00:41:24 +0100 (CET)
On Wed, 23 Mar 2022, Mark Gaiser via curl-library wrote:
> - ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
> becomes this format:
> - <gateway>/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
> with an actual example being:
So there's never any path or query in an ipfs URL? How about fragment?
What should happen if a path or query is specified?
> - seturl (urlapi.c line 805) doesn't understand "ipfs://<cid>" and
> considers <cid> to be the "host".
Now you're talking about the url API and that's libcurl code.
Of course libcurl has no magic special knowledge of ipfs:// URLs, and from
previous discussions we learned that there also is no ipfs URL syntax
standard. Is there one now?
URLs are made to be generic. Why does the parser need to know about ipfs? Ig
the <cid> is the host from the URL, does that matter?
> An approach that could potentially work is:
> 1. Let parseurl fail with "ipfs://" (actually seturl, but called from
> parseurl)
Then you're talking about libcurl code. I thought we agreed that this change
would be commandline tool only? The tool code is all in src/.
Date: Thu, 24 Mar 2022 00:41:24 +0100 (CET)
On Wed, 23 Mar 2022, Mark Gaiser via curl-library wrote:
> - ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
> becomes this format:
> - <gateway>/ipfs/QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
> with an actual example being:
So there's never any path or query in an ipfs URL? How about fragment?
What should happen if a path or query is specified?
> - seturl (urlapi.c line 805) doesn't understand "ipfs://<cid>" and
> considers <cid> to be the "host".
Now you're talking about the url API and that's libcurl code.
Of course libcurl has no magic special knowledge of ipfs:// URLs, and from
previous discussions we learned that there also is no ipfs URL syntax
standard. Is there one now?
URLs are made to be generic. Why does the parser need to know about ipfs? Ig
the <cid> is the host from the URL, does that matter?
> An approach that could potentially work is:
> 1. Let parseurl fail with "ipfs://" (actually seturl, but called from
> parseurl)
Then you're talking about libcurl code. I thought we agreed that this change
would be commandline tool only? The tool code is all in src/.
-- / 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/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-03-24