Even embedded OSs support this, and the convention is to look there before consulting DNS. This happens behind the system calls that do name resolution, so it's transparent to cURL - and anything else. For GNU systems, this is in glibc (and see /etc/nsswitch.conf for resolution order). Let the OS do its job, don't re-invent the wheel.
This supports all the use cases for all applications.Building something custom into cURL only gets you cURL - and when you want to do something else (notify someone via mail, or SMS, or ...) you're back to either doing it via cURL, or trying to force your own name resolution into the next application.
Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On 22-Nov-21 15:14, Marcel via curl-library wrote:
Hey Dan, On 22.11.21 20:54, Dan Fandrich via curl-library wrote:Is the problem that the name doesn't resolve at all or resolves incorrectly?Unfortunately the first case. My device does not have internet access and we would like to use the modem to send maintenance data to a server.If the former, I would think you could just extract the host name from the URL using the curl_url API and populate the DNS cache after resolving the name yourself.That sounds like a good solution. I'll try that tomorrow.There are a few boundary cases (redirects, certificate revocation checks,proxies, etc.) with this approach but the simple cases should work fine.Because I control the server, that should be good :) Thanks for your answer!Would you think extending the CURL API to allow my usecase would be a good idead?Regards, Marcel
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
