Closed Bug 1368640 Opened 4 years ago Closed 2 years ago

flyweb: service name split on dot


(Core :: Networking, defect, P5)






(Reporter: chrysn, Unassigned)



(Whiteboard: [necko-would-take])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170419202525

Steps to reproduce:

In firefox nightly (firefox-55.0a1.en-US.linux-x86-64.tar.bz2), enable flyweb, go to the website and allow the page to start a server.

Start `avahi-browse -a` to see the announced " Remote Control" service, and wireshark in parallel.

Actual results:

avahi-browse finds a service called "flyweb" with no type and a " Remote Control._flyweb._tcp._local" service.

The components of the mDNS packages shown in wireshark are (in mixed hex/ascii notation) 06 "flyweb" 06 "github" 11 "io Remote Control" 07 "_flyweb" 04 "_tcp" 05 "local".

Expected results:

avahi-browse should have shown a " Remote Control" service of type _flyweb._tcp in the local domain. (As a consequence, flyweb services could be made discoverable with the existing ciaociao extension).

The DNS result should have been something like 1f " Remote Control" 07 "_flyweb" 04 "_tcp" 05 "local".

For standard reference, see RFC 6763 section 4.1.1 that the instance name may indeed contain dots, and "is stored directly in the DNS as a single DNS label".

(Yes, this interacts oddly with the DNS entries in dot-serialized form; section 4.3 has something on backslash-escaping dots in text form. With flyweb's UUID hostnames, there's no reason this should be required anywhere, though.)
Blocks: flyweb
Component: Untriaged → Networking
Product: Firefox → Core
Thanks for reporting this chrysn. Unfortunately, I think the plan for FlyWeb is to remove it from Gecko core codebase.  The prototype implementation has bitrotted significantly and we made the decision a while back to move to an app-based approach (and re-do the gecko implementation once we validate the concept outside of gecko).

Both of the team members (me and Justin) are occupied with other work ATM, too.
That's a shame, given the DNS-SD part in the browser would fill one of the last gap in the "IoT done using web technology" story.

Is there any more public place where the abandoning of FlyWeb is discussed / announced, where I can make that point more prominently or meet up with other would-like-to-be users of in-browser discovery?
Whiteboard: [necko-would-take]
Bulk change to priority:
Priority: -- → P5
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.