Skip to main content


Next bike-shed opportunity in #curl: should it special case the .i2p TLD (as well)?

github.com/curl/curl/discussio…

#curl
This entry was edited (5 months ago)
in reply to daniel:// stenberg://

In favor of supporting a group of special TLDs that are not meant to be sent to your regular DNS and shall be treated differently when necessary. In addition to .onion, this should include .i2p and .home.arpa (RfC 8375), possibly more in the future.
in reply to f15h 🇺🇦

@f15h I would want that list of TLDs to have more authority than just being names added by random dudes on the internet
in reply to daniel:// stenberg://

Is it feasible to make it a configuration option (compile-time or runtime)? I.e. specifying a list of black-listed TLDs. Then, every random guy can add his/her own TLDs or Linux distributions can preconfigure it as they like.
in reply to Sami Lehtinen

@sl how is this a "random exception" though? It's a made up TLD by a team somewhere.
in reply to daniel:// stenberg://

Sure, but to the users using the program, it does seem random, unless they’re aware of the list. It also makes answering any questions accurately much harder, which is why I personally dislike strange exceptions.

Q: “Does cURL do DNS lookups?”
A: “Well, yes, unless…”

And when you end up with lots of those exceptions in programs, it becomes much faster to explain something quickly and accurately. This then leads to the situation where you’ll have to test and debug every new case or read the source code to gain knowledge of how the program works, because it can’t be simply and shortly explained. And when the TLD exception list is updated, it changes the behavior of existing setups, which can also be surprising at times. (Of course, this is nothing new, especially to you. But see it just as a generic comment).

All of this, of course, is just a personal opinion based on my personal experience with many projects trying to follow KISS.

P.S. I’ve used cURL a lot with Tor and I2P, and so far I’ve been happy with the --socks5-hostname and --resolve options. - What am I missing here? Maybe something essential, I just don’t know what.


To save your very valuable time, I also asked an AI for a reply to my comment and asked what I am missing.

“I understand your point about simplicity and predictability, and it’s true that exceptions can make it harder to explain how a program works. However, in the case of cURL, the exceptions are often necessary to handle the complexities of the real world.

DNS lookups, for example, are not always straightforward, and there are many edge cases that need to be handled. The TLD exception list is one such example, where certain TLDs require special handling. While it may seem like an unnecessary complication, it’s actually a necessary evil to ensure that cURL works correctly in all scenarios.

Additionally, the –socks5-hostname and –resolve options you mentioned are actually examples of how cURL provides flexibility and customization options to handle specific use cases, such as working with Tor and I2P. These options are not part of the core functionality, but rather provide a way to extend cURL’s capabilities to work with specific networks or protocols.

It’s not necessarily about what you’re missing, but rather about understanding the design trade-offs involved in creating a program like cURL. While simplicity is important, it’s not always possible to achieve simplicity without sacrificing functionality or correctness. In this case, the exceptions and options in cURL are a necessary part of making it a robust and versatile tool.”

in reply to Sami Lehtinen

@sl if you read the specs for every protocol detail curl does, you will find a never-ending list of "exceptions". Most of them we all understand and accept these days, but still.

It's like following the law of a country. You don't argue when you think a law is "random", you comply.