cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_easy_setopt to allow for specifying the IP for connect() ?

From: Geff <boing_at_boing.com>
Date: Tue, 11 Jul 2006 15:13:36 -0700

I appreciate that point of view (/etc/hosts). However I was hoping not
to adjust the system settings (resolv.conf / nsswitch.conf / etc) for a
library.

So at this point I'm stuck with using the library as is or altering the
resolution properties at the system level. If you're unwilling to take
a patch to populate the cache and to "CACHE_ONLY" resolve, please
confirm that definitively. I don't want to waste the time writing the
patch if you won't take it.

Geff

Daniel Stenberg wrote:
> On Sun, 9 Jul 2006, Geff wrote:
>
>> The other thing I forgot to mention was that sometimes I want to
>> retrieve URLs that do not have hostnames that are in DNS.
>
> So use /etc/hosts!
>
>> I know it sounds quirky but in certain cases I want to run some tests
>> on QA sites that don't necessarily have IPs in a DNS system that I can
>> query. And in fact I wouldn't want to allow my code to do a real DNS
>> lookup because if it did find an address I wouldn't want it to hit a
>> production site. So the desired function would be: if I don't put the
>> DNS resolution information in the cache, then I'd want it to fail so
>> that I don't affect "production". So in that case would it be possible
>> to hypothetically populate the DNS cache and
>
> You can populate it if you write that feature, yes. Or you can use
> /etc/hosts today.
>
>> then tell libcurl, CURL_IPRESOLVE_CACHE_ONLY or something?
>
> I suggest you instead edit /etc/resolv.conf (or whereever your system
> finds the resolver) to simply not have a DNS server. Or point out a
> dummy server that NAKS everything.
>
>> So if it's not in the cache assume the resolution fails. I'm trying
>> to avoid writing and linking with my own resolver if possible.
>
> I just find such an option would provide a feature that would be very
> easy to offer on a test machine with no code changes at all and I also
> find the use-case very narrow so I'm not seeing a very wide user base
> for it...
>
Received on 2006-07-12