CURLOPT_RESOLVE and nearly expired DNS Cache entries: replace old entry #2622

Closed
wants to merge 4 commits into
from

Conversation

Projects
None yet
3 participants
@ajorajev

ajorajev commented May 30, 2018

We use CURLOPT_RESOLVE to tell Curl to use specific addresses instead of doing real DNS lookup.

when cached address is already there (saved by Curl internally) and close to expire, then by the time next http request is made, it can get expired.

Partial fix would be to mark existing entry as set by CURLOPT_RESOLVE (by setting timestamp to zero). This will keep this entry permanently in the cache as intended.

However, currently, if the cache entry already exists, CURLOPT_RESOLVE just leaves it, thus
an old address remains (while calling code expects new address to be saved).

Let's say that cURL already looked up "example.org" recently and found its IP address to be 1.1.1.1.
As usual, it's stored in the relevant DNS cache. Then, later, we issue a new request that uses the same DNS cache, and that 1.1.1.1 entry is still in the cache.

Then, if we do:
curl_easy_setopt(handle, CURLOPT_RESOLVE, [ "example.org:80:2.2.2.2" ]); and then issue the new request, we want this current request to use 2.2.2.2 as its IP

So it is best if we always override existing entries.

ajorajev and others added some commits May 30, 2018

Merge pull request #1 from curl/master
taking latest to my own fork
@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder May 30, 2018

Member

Thanks, try make checksrc to make sure there's no style warnings. The CI found this nit:

./unit1609.c:128:54: warning: sizeof without parenthesis (SIZEOFNOPAREN)
     int addressnum = sizeof tests[i].address / sizeof *tests[i].address;
                                                      ^
Member

bagder commented May 30, 2018

Thanks, try make checksrc to make sure there's no style warnings. The CI found this nit:

./unit1609.c:128:54: warning: sizeof without parenthesis (SIZEOFNOPAREN)
     int addressnum = sizeof tests[i].address / sizeof *tests[i].address;
                                                      ^
@ajorajev

This comment has been minimized.

Show comment
Hide comment
@ajorajev

ajorajev May 31, 2018

thanks, just fixed now, will always run "make checkrsc" from now on.

thanks, just fixed now, will always run "make checkrsc" from now on.

.gitignore
@@ -1,3 +1,4 @@
+.DS_Store

This comment has been minimized.

@bagder

bagder May 31, 2018

Member

I don't think this belongs here.

@bagder

bagder May 31, 2018

Member

I don't think this belongs here.

This comment has been minimized.

@ajorajev

ajorajev May 31, 2018

this is local file, which MacOS creates to store custom attributes of its containing folder (position of icons, etc.). when I create local GIT copy, this file is always coming up and I assume it happens to other developers (who use Mac).
but yes, having perused all content of .gitignore I can see that it contains wildcards to files related to Curl itself. I will remove this now and check is there way to configure GIT locally to ignore some files.

@ajorajev

ajorajev May 31, 2018

this is local file, which MacOS creates to store custom attributes of its containing folder (position of icons, etc.). when I create local GIT copy, this file is always coming up and I assume it happens to other developers (who use Mac).
but yes, having perused all content of .gitignore I can see that it contains wildcards to files related to Curl itself. I will remove this now and check is there way to configure GIT locally to ignore some files.

This comment has been minimized.

@ajorajev

ajorajev May 31, 2018

ok, I found solution - I can have my own gitignore using:

git config --global core.excludesfile ~/.gitignore

@ajorajev

ajorajev May 31, 2018

ok, I found solution - I can have my own gitignore using:

git config --global core.excludesfile ~/.gitignore

This comment has been minimized.

@jzakrzewski

jzakrzewski May 31, 2018

Contributor

Maybe explicitly ignoring all dot-files + whitelisting those we need wouldn't be a bad idea?

@jzakrzewski

jzakrzewski May 31, 2018

Contributor

Maybe explicitly ignoring all dot-files + whitelisting those we need wouldn't be a bad idea?

This comment has been minimized.

@bagder

bagder May 31, 2018

Member

I don't see a need for that. I think we should stick to ignoring files that are generated by a curl build. If you want to ignore more files, it is very easy to do what @ajorajev did and just set your own ignore files for those - I do that too.

@bagder

bagder May 31, 2018

Member

I don't see a need for that. I think we should stick to ignoring files that are generated by a curl build. If you want to ignore more files, it is very easy to do what @ajorajev did and just set your own ignore files for those - I do that too.

This comment has been minimized.

@jzakrzewski

jzakrzewski Jun 1, 2018

Contributor

I thought the same before I've spotted Vim, Eclipse, and backup files typical for Pluma/GEdit/etc there. But I won't argue on it.

@jzakrzewski

jzakrzewski Jun 1, 2018

Contributor

I thought the same before I've spotted Vim, Eclipse, and backup files typical for Pluma/GEdit/etc there. But I won't argue on it.

This comment has been minimized.

@bagder

bagder Jun 1, 2018

Member

Right, but I consider editor backup files to be sort of "generated by a curl build" or at least "created as a result of someone working on curl".

@bagder

bagder Jun 1, 2018

Member

Right, but I consider editor backup files to be sort of "generated by a curl build" or at least "created as a result of someone working on curl".

Alibek.Jorajev
removing DS_Store from .gitignore, it turned out that gitignore conta…
…ins wildcards related to Curl build, not local OS
@bagder

This comment has been minimized.

Show comment
Hide comment
@bagder

bagder Jun 1, 2018

Member

Thanks!

Member

bagder commented Jun 1, 2018

Thanks!

@bagder bagder closed this in f66d97b Jun 1, 2018

@ajorajev

This comment has been minimized.

Show comment
Hide comment
@ajorajev

ajorajev Jun 1, 2018

thank you too.

ajorajev commented Jun 1, 2018

thank you too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment