GNOME Bugzilla – Bug 332759
ZeroConf/MDNS discovered "local ZeroConf/MDNS discovered "local sites" should use host-name
Last modified: 2007-07-23 14:03:26 UTC
Please describe the problem: As received in the debian bts (#352703) Hi, ZeroConf/MDNS websites are currently always accessed via http://ip.ip.ip.ip/path this obviously doesn't work too well with Virtual Hosts. Therefore, Epiphany should access them using the supplied hostname (at least as long as the name resolves properly) I'm using zeroconf to announce important local websites; they resolve globally, but some of them are virtual hosts. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Looks like a problem in the gnome-vfs-dns-sd backend with avahi. From gnome-vfs-dns-sd.c:avahi_resolve_async_callback, the gnome_vfs_dns_sd_resolve callback will always get the host as IP address. avahi_resolve_async_callback itself does get the host_name as text too; I'd like to have a way to retrieve it. And the docs for gnome_vfs_dns_sd_resolve need to be adjusted to say that.
I am voting for passing the flag AVAHI_LOOKUP_NO_ADDRESS to avahi_service_resolver_new in gnome_vfs_dns_sd_resolve and gnome_vfs_dns_sd_resolve_sync for satisfying the spec given in the API docs. Was wondering about that already, when working on bug 332634, but didn't care enough to solve that issue. :-/
Created attachment 60264 [details] [review] Behave as documented: Don't resolve A/AAAA records in gnome_vfs_dns_sd_resolve and gnome_vfs_dns_sd_resolve_sync As a side effect pseudo local services without a DNS entry work in Nautilus' network environment now.
What does this mean for "foo.local" addresses? Will those be returned as the resolved ip or as "foo.local"? Lots of OSes are not set up to resolve "foo.local" via mDNS.
Not handled by the patch. Guess when talking to them via HTTP, we have to pass the "foo.local" name with the "Host" request header, as there is some chance, that "foo.local" is a virtual host. As applications using the DNS-SD API should be aware of the "foo.local" issue, we should delegate the responsibility for resolving "foo.local" names to them - supported by some very BOLD HINT about that issue in the API docs. Only problem: gnome-vfs doesn't expose API for resolving hostnames via mDNS so far, so we might need wrappers for "avahi_host_name_resolver_new" and friends: gnome_vfs_dns_sd_resolve_hostname, gnome_vfs_dns_sd_cancel_resolve_hostname and gnome_vfs_dns_sd_resolve_hostname_sync.
Created attachment 60355 [details] [review] This patch now resolves A/AAAA records for .local hosts Decision to resolve .local hosts could be based upon the result of avahi_nss_support(), but that function just checks for existance of the mdns NSS module, so this function won't work on BSD or Solaris. As it also doesn't check for activation of nss_mdns in nssswitch.conf, it also does not work reliable on Linux. So I guess it's better to ignore avahi_nss_support() for now.
How serious is this bug? I guess it's not serious enough to break hard code freeze .. opinions?
> How serious is this bug? I guess it's not serious enough to break hard code freeze According to [1] the hard code freeze begins in 5 days. [1] http://live.gnome.org/TwoPointThirteen
Ok .. so I suck, but that's old news .. I am going to have a look at it later ..
Created attachment 60436 [details] [review] gnome-vfs-bug-332759-r2-step1-move-avahi_resolve_sync_client_callback.patch Step1: move avahi_resolve_sync_client_callback
Created attachment 60437 [details] [review] gnome-vfs-bug-332759-r2-step2-insert-avahi_resolve_host_name.patch Step2: insert avahi_resolve_host_name
Created attachment 60438 [details] [review] gnome-vfs-bug-332759-r2-step3-resolve-dot-local-names.patch Step3: resolve .local names
Created attachment 60439 [details] find-ssh.c Makefile for the test program: GNOMEVFS_CFLAGS=$(shell pkg-config --cflags gnome-vfs-2.0) GNOMEVFS_LDLIBS=$(shell pkg-config --libs gnome-vfs-2.0) CFLAGS+= -Wall -W -Werror -g -O0 all: find-ssh find-ssh test-case: CFLAGS+= $(GNOMEVFS_CFLAGS) find-ssh test-case: LDLIBS+= $(GNOMEVFS_LDLIBS)
Do we really need to kick off a full new resolve? Don't we have the address already? I mean, that was the initial problem, that we always used the address instead of the hostname. I'm very wary about large changes this late in the cycle, and this patch is sort of large.
Yes, the service resolver callbacks look, as if they would provide both hostname and address at the same time - but unfortunatly this is not true: If you do not pass any flags to the service resolvers, you only get the IP address, but no hostname (which is quite confusing); if you pass AVAHI_LOOKUP_NO_ADDRESS, you do not get the IP address (as expected). So we are resposible for resolving .local addresses. As we want to resolve .local addresses, we have to use multicast. As gnome-vfs has no function for resolving mDNS, we need a new function. The function uses exactly the same algorithm as the other synchronious resolvers. Only changed resource cleanup to some more robust pattern ("try/finally" simulated via "goto cleanup"). Last patch utilizes the new function in the minimal possible way (I can think of). Regarding size of the patch: Had a similiar feeling - that's why I seperated it into three small patches, which should be easy to verify. First patch just moves some static functions to the top of the file. Second one doesn't move arround any code, just introduces the new resolver. If this function should be broken, then all synchronious resolvers have the very same problem. So hope this helps to make your decision, wheither this goes into 2.14, 2.14.1 or 2.16. Thanks for reviewing.
*** Bug 337679 has been marked as a duplicate of this bug. ***
Can this be applied before 2.16 freeze, please?
When will this be applied ?
could be a good idea to send the patch on the gnomevfs list, maintainers usually review patches on the list
commited.