-
Notifications
You must be signed in to change notification settings - Fork 325
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
Revisiting dnslink support with X-Ipfs-Path #548
Comments
Improved flow suggestion, after conversation with @lidel on IRC.
|
Thank you for sharing. It is an interesting idea, but I see two problems with it:
It just not reliable enough, I am afraid. |
Can we discuss this a little more before closing the issue? My entire point here is that the optional usage of dnslink actually is a no-usage, even more if you consider the frightening warning in the options page. If we could come up with a solution that isn't as slow as the current dnslink stuff so that it could be enabled by default that would be good overall.
Fair enough, but the presence of
If the HTTP server is down, currently the website won't work anyway, as the dnslink setting will be disabled;
If it doesn't work for initial requests, then it could check the dnslink and redirect all requests to the local IPFS daemon as soon as
Well, in this other issue you've said that "we only need to read response headers before connection is aborted, the overhead is minimal and I believe it is worth it" when talking about |
(Revisiting after a nap, jump to the end for quick summary) I am sorry, bit jet-lagged today. I really appreciate this discussion, thank you for your ideas!
This is quite interesting apprach, but comes with some trade-offs.
Yes, this is the pain point. Right now dnslink experiment enables DNS TXT lookups via HTTP API: http://127.0.0.1:5001/api/v0/dns/docs.ipfs.io I really hoped we would have a WebExtension API for running efficient DNS TXT lookups by now, that would remove performance factor entirely, but that issue is still open and won't happen any time soon. I agree we could try alternative approach to dnslink before that API lands.
Note that dnslink experiment is off by default on purpose. I understand it is frustrating it is not on by default, but we want to get it right before we enable it for all users. That includes accounting for all edge cases, including HTTP server being down.
Agreed. 👍 The only missing pieces in this approach are:
Yes, overhead is not a problem here, it is smaller than HTTP-based DNS TXT lookup done by current dnslink implementation. What i meant by "just too late", is that
TL;DROh wow, I should make this shorter, but don't have time, so let me just summarize:
|
Side question: should This is a scenario when someone exposes My initial intuition is that it is okay: it would be just what we do right now with Thoughts? |
I just went with it and implemented DNSLink policy that takes advantage of More details in PR #558 |
Instead of doing TXT DNS request for every site when the "dnslink" option is set, why not listen for the
.onHeadersReceived
events (since these are already being listened for anyway) and look for theX-Ipfs-Path
header?The text was updated successfully, but these errors were encountered: