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: Custom resolve of Address
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Mon, 22 Nov 2021 16:41:50 -0500
On 22-Nov-21 16:06, Marcel Hellwig via curl-library wrote:
>
> On 22.11.21 21:33, Timothe Litt via curl-library wrote:
>>
>> Why not just put the entries you need into hosts.txt ( Actually
>> /etc/hosts or \Windows\System32\drivers\etc\hosts, or equivalent)?
>>
> Because I don't know the host names beforehand.
>
>> 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.
>>
> I only want curl. Maybe I wasn't clear enough.
> The device has *no* internet access at all. The only way to connect to
> the internet is through this application. Linux doesn't own or handle
> the device.
>
>
> - Marcel
There would seem to be 3 cases:
1) you have an initial IP address but don't know what its name will be
in a particular installation.
2) you have a name, but don't know what it's address is
3) you have neither until some out-of-band mechanism delivers one or both
In case 1, it doesn't matter what the name is. Call it "Fred". All an
application needs is the IP address.
Case 2 is classic name resolution. The address has to come from
somewhere. You can put it in the DNS - but as you don't have internet
(or apparently even a local resolver), put it in a file. /etc/hosts is
already there
Case 3, nothing is going to happen until the out-of-band mechanism
delivers - at which point it reduces to 1 or 2.
/etc/hosts doesn't require internet access. And it doesn't care about
what device you use to communicate. It just does name resolution.
Assuming a POSIX system, /etc/nsswitch just needs a line like "hosts:
files" to tell (g)libc to look to /etc/hosts and not look to dns.
If you're using cURL, you (almost) always end up with an IP address.
You can connect to your server by address (in your case, typically an
rfc1918 or IPv6 private address). If, as it seems, you want a name, you
can call it anything you want in /etc/hosts.
E.g.
server 192.168.0.4
or
my.strange.server.mydomain.example.net 10.0.0.4 10.12.3.4 2001::123
You can update /etc/hosts if the address changes, is discovered later,
or is delivered over your private scheme.
If you are providing your own socket and read/write over some
proprietary protocol, I don't understand why you need name resolution
integrated with cURL's cache. But if what you want to end up with looks
like an IP address, /etc/hosts will do the mapping.
If you roll your own, you're going to end up with a name and an
address. You'll probably store it in a file of some sort, read the
file, and update cURL's cache. This is at least as much work as
updating /etc/hosts - which your OS will still have the code to handle.
You're not gaining anything by going this route, and what you end up
with is much more limited.
You really want to the the OS do it's job. Name resolution is a solved
problem - originally via hosts.txt (now /etc/hosts), as well as by DNS,
LDAP, and many other technologies. You should spend your creativity
doing something more valuable than reinventing solutions.
As for "I only want curl" - I'm sure that's true. Today. But things
change. I have decades of examples - from 4-bit embedded computers to
mainframes. Customers, product managers, and yes, even engineers,
always find reasons to improve the product.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2021-11-22
Date: Mon, 22 Nov 2021 16:41:50 -0500
On 22-Nov-21 16:06, Marcel Hellwig via curl-library wrote:
>
> On 22.11.21 21:33, Timothe Litt via curl-library wrote:
>>
>> Why not just put the entries you need into hosts.txt ( Actually
>> /etc/hosts or \Windows\System32\drivers\etc\hosts, or equivalent)?
>>
> Because I don't know the host names beforehand.
>
>> 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.
>>
> I only want curl. Maybe I wasn't clear enough.
> The device has *no* internet access at all. The only way to connect to
> the internet is through this application. Linux doesn't own or handle
> the device.
>
>
> - Marcel
There would seem to be 3 cases:
1) you have an initial IP address but don't know what its name will be
in a particular installation.
2) you have a name, but don't know what it's address is
3) you have neither until some out-of-band mechanism delivers one or both
In case 1, it doesn't matter what the name is. Call it "Fred". All an
application needs is the IP address.
Case 2 is classic name resolution. The address has to come from
somewhere. You can put it in the DNS - but as you don't have internet
(or apparently even a local resolver), put it in a file. /etc/hosts is
already there
Case 3, nothing is going to happen until the out-of-band mechanism
delivers - at which point it reduces to 1 or 2.
/etc/hosts doesn't require internet access. And it doesn't care about
what device you use to communicate. It just does name resolution.
Assuming a POSIX system, /etc/nsswitch just needs a line like "hosts:
files" to tell (g)libc to look to /etc/hosts and not look to dns.
If you're using cURL, you (almost) always end up with an IP address.
You can connect to your server by address (in your case, typically an
rfc1918 or IPv6 private address). If, as it seems, you want a name, you
can call it anything you want in /etc/hosts.
E.g.
server 192.168.0.4
or
my.strange.server.mydomain.example.net 10.0.0.4 10.12.3.4 2001::123
You can update /etc/hosts if the address changes, is discovered later,
or is delivered over your private scheme.
If you are providing your own socket and read/write over some
proprietary protocol, I don't understand why you need name resolution
integrated with cURL's cache. But if what you want to end up with looks
like an IP address, /etc/hosts will do the mapping.
If you roll your own, you're going to end up with a name and an
address. You'll probably store it in a file of some sort, read the
file, and update cURL's cache. This is at least as much work as
updating /etc/hosts - which your OS will still have the code to handle.
You're not gaining anything by going this route, and what you end up
with is much more limited.
You really want to the the OS do it's job. Name resolution is a solved
problem - originally via hosts.txt (now /etc/hosts), as well as by DNS,
LDAP, and many other technologies. You should spend your creativity
doing something more valuable than reinventing solutions.
As for "I only want curl" - I'm sure that's true. Today. But things
change. I have decades of examples - from 4-bit embedded computers to
mainframes. Customers, product managers, and yes, even engineers,
always find reasons to improve the product.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature