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.html
