-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
CURLOPT_RESOLVE and nearly expired DNS Cache entries: replace old entry #2622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
taking latest to my own fork
Thanks, try
|
thanks, just fixed now, will always run "make checkrsc" from now on. |
.gitignore
Outdated
@@ -1,3 +1,4 @@ | |||
.DS_Store |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this belongs here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I found solution - I can have my own gitignore using:
git config --global core.excludesfile ~/.gitignore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe explicitly ignoring all dot-files + whitelisting those we need wouldn't be a bad idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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".
…ins wildcards related to Curl build, not local OS
Thanks! |
thank you too. |
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.