It is worrisome because it is doing something more than what I want from
it.

While I am evaluating whether to use it in my application or not I need to
make sure that I am aware of all effects that CURLOPT_RESOLVE can have.

Hence, the need to ask someone on the forum whether there are any risks
involved. Since, you say it's not risky at all, I can go ahead with it.

I have another relevant question.

If I use CURLOPT_RESOLVE, it is expected that I also have to do DNS
resolution in my application and get the IP before calling CURLOPT_RESOLVE,
right?

For me as a developer it would have been a single line code change if I
only had to use a simple CURLOPT that sets the Server name extension for me.

Now with CURLOPT_RESOLVE I need to make code changes for accommodating DNS
resolve as well as removing the old entry in case the IP has changed.

What could be the drawbacks in using a new CURLOPT to set SNI, I'm just
curious here.

On Mon, Jul 30, 2018 at 9:45 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 30 Jul 2018, Alisha Joshi wrote:
>
> I have referred to this : https://curl.haxx.se/mail/arch
>> ive-2015-01/0042.html and tried using it in my application and it works.
>> However, I find it worrysome that CURLOPT_RESOLVE option pre-populates the
>> DNS cache with entries for the host+port pair.
>>
>
> Why is that "worrysome" ?
>
> My intention is just to send Server name extension and not change any DNS
>> properties.
>>
>
> But if it gets you the same end results, does it really matter *how* it
> was done?
>
> I would like to know why it was found better to use CURLOPT_RESOLVE to set
>> Server Name instead of providing a new CURLOPT to set Server Name?
>>
>
> I wouldn't say it is "better", but it is an existing method/option that
> already exist and for most purposes can accomplish the same things making
> the question the reversed:
>
> Why should we add a new option if you can get your thing done using an
> existing option?
>
> Also are any risks associated with using CURLOPT_RESOLVE to set Server
>> Name?
>>
>
> I can't see why it would be risky at all.
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-08-16