-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Fix: dnslink domain resolving was broken; Add: no caching for those #1272
Conversation
Thanks this is great. sorry for the resolve errors. |
if len(host) > 0 && isd.IsDomain(host) { | ||
name := "/ipns/" + host | ||
if _, err := n.Namesys.Resolve(ctx, name); err == nil { | ||
r.URL.Path = path.Join("/ipns/", host) + r.URL.Path |
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: name + r.URL.Path
?
And we probably want to some tests with a mock DNS resolver (like
namesys/dns_test.go) to make sure this doesn't break again. I think
that means we want a public API in namesys to manage the resolver (and
probably also the publisher) maps in mpns. That's a bit awkward at
the moment, because the ‘resolver’ interface is internal. Maybe
namesys needs public backend APIs (currently the mpns type, the
resolve helper, and the resolver interface) along side it's current
public frontent APIs (the Resolver, Publisher, and NameSys
interfaces).
|
Just using Regarding two DNS resolves: I don't the the problem with this. The DNS entry is cached by the next DNS resolver in the network. For most people their local router, otherwise providers router, … So this are two inexpensive DNS requests compared to one… Yeah sure, one could implement a DNS cache but for now it would work for me this way. |
About tests: @jbenet and me had an idea for this: https://botbot.me/freenode/ipfs/2015-05-21/?msg=39768745&page=5 |
On Thu, May 21, 2015 at 10:34:41AM -0700, Knut Ahlers wrote:
Ah, that makes sense. All these little wrinkles to trip us up :p. |
On Thu, May 21, 2015 at 10:40:14AM -0700, Knut Ahlers wrote:
I just see “we need to test this” there, not how to get a mock DNS for |
We have several tests for the resolver stuff but none of those caught the feature to be fully destroyed. A full-stack-test would test the whole stack and check the "outside" functionality is still intact and not only parts of the codes are okay. |
we should have a few domains on ipfs.io, like |
On Thu, May 21, 2015 at 11:14:21AM -0700, Jeromy Johnson wrote:
Tests that require a working network connection between the location |
Yep, absolutely. if people drop some records here, i'll add them.
Agreed with this too. I think we should have a test that is usually mocked, but the mocking can be turned off and run live when in the internet (on CI). (good to test for real). |
@Luzifer should i merge this, or wait for tests? |
@jbenet for me it would really nice to have this live and working |
Actually I'd prefer someone with more knowledge about the whole project and mocking to write the tests… |
@wking do you think you could handle writing a test or two for this? |
circlci's detecting races for us :) cc @whyrusleeping
|
Fix: dnslink domain resolving was broken; Add: no caching for those
(let's do a test as a separate PR -- #1289) |
Fix: dnslink domain resolving was broken; Add: no caching for those This commit was moved from ipfs/kubo@4e71ce3
fixes #1234 & #1267
@jbenet PTAL