Case of keys should be ignored about mdns-sd

[dalepsmith]

Yes! I've been meaning to get to that. Life is kind of busy at the moment. In the middle of a job search. Thanks for your patience.

…

-Dale

[dalepsmith]

This for case #77

[keepsimple1]

@dalepsmith could you please help check if #82 works for you?

[dalepsmith]

On 1/26/23, keepsimple1 ***@***.***> wrote: @dalepsmith could you please help check if #82 works for you?

Checking it...

…

-Dale

[dalepsmith]

So when I publish a service with `avahi-publish-service Testing _foo._tcp 1234 path=one Path=two PaTh=three` I see messages with tcpdump like `15:05:26.632340 IP deb-test.mdns > 224.0.0.251.mdns: 0*- [0q] 5/0/0 PTR Testing._foo._tcp.local., (Cache flush) TXT "path=one" "Path=two" "PaTh=three", (Cache flush) SRV deb-test.local.:1234 0 0, (Cache flush) AAAA fe80::a00:27ff:fea8:a09b, (Cache flush) A 192.168.1.69 (163)` Notice that the order of the various cases of "path" is maintained. (That's probably a bug, but it *does* stuff several different-cased TXT values in the packet) My test code shows this: `15:05:11.599137 = {"type":"add","service":"Testing","srv":"_foo._tcp","hostname":"deb-test.local.","address":"192.168.1.69","port":1234,"txt":{"Path":"two"}}` Good news, it's only showing one "path". Bad news, it's not the first, but the second...

…

-Dale

[keepsimple1]

Thank you very much for checking it! I will look into it.

[keepsimple1]

Thanks again for the testing. I've made the following changes:

1. Use a Vec store the TXT properties: to keep the original order from the user input. (If the user passes in HashMap, then the ordering might not always be the same due to the nature of HashMap, but passing a slice should be good).

2. Based on this quote from RFC 6763:

If a client receives a TXT record containing the same key more than
   once, then the client MUST silently ignore all but the first
   occurrence of that attribute. 

Now the client side will only record the first key appearance.

3. Base on this quote from the same RFC:

A given key SHOULD NOT appear more than once in a TXT record.

Now the server side will only publish the first key appearance as well. This is different from avahi-publish-service based on your log, but I think it matches better with the RFC.

Let me know what you think and if it's working for you now. Thanks!

[keepsimple1]

My testing shows that with the PR, we are doing:

1. Treat the key as case insensitive. If there are multiple properties with the same key, only the first one is recorded.
2. The same goes for publishing. If multiple properties have the same key, only the first one is published.
3. The order of properties is kept as the order provided by the caller.

I'm shooting for merging this PR in a couple of days. If any comments or issues, please let me know. Thanks!

[keepsimple1]

I've merged in PR #82 . If any issues, please let me know.

[keepsimple1]

A version (0.6.0) is published, closing this issue. If any problems, please open a new issue.

[dalepsmith]

On 2/1/23, keepsimple1 ***@***.***> wrote: Thanks again for the testing. I've made the following changes: 2. Based on this quote from RFC 6763: ``` If a client receives a TXT record containing the same key more than once, then the client MUST silently ignore all but the first occurrence of that attribute. ``` Now the client side will only record the first key appearance.

So I've *finally* been able to look at this again! Sorry for the delay, New job and other things keep getting in the way.. Publishing a service with $ avahi-publish-service "Testing" _test._tcp 80 one=1 ONE=2 One=3 And using my application subscribing to "_test._tcp" I see _test._tcp 19:30:39.515780 = {"type":"add","service":"Testing","srv":"_test._tcp","hostname":"debmetrix.local.","address":"192.168.1.180","port":80,"txt":{"One":"3","one":"1","ONE":"2"}} I would have expected to just see the "one=1" key. (The code I'm testing with is at https://bitbucket.org/dalepsmith/rust-mdns-discover/src/master/ ) Maybe I'm using the updated api incorrectlly? Everything else looks great! Thanks so much.

…

-Dale

[keepsimple1]

I would have expected to just see the "one=1" key.

You're correct. This is a bug. Thanks for checking! I've opened a PR to fix this. Sorry I missed this path earlier somehow.

Btw, congrats to your new job! hope everything go well for you.

[keepsimple1]

The remaining issue is fixed in release 0.7.1. Closing this issue (again ;-) now.