[avahi] Inconsistent orders of TXT argument in Avahi client API

[Petr Menšík]

I am not sure why is the order of records interesting. In general DNS 
records to not have set order in which they should be received. Unicast 
DNS even randomizes the first record. If you rely on specific order of 
TXT records, please don't. It would be nice to have it always processed 
the same way. But any application should not rely on their order.

Or have I understood it wrong way?

Regards,
Petr

On 2/14/23 09:02, Handa Wang wrote:
> Hello,
>
> (This is the same as issue #436 
> <https://github.com/lathiat/avahi/issues/436>.)
>
> It seems that in `avahi_entry_group_add_service_strlst` the passed in 
> TXT argument is reversed before passing to the server: 
> https://github.com/lathiat/avahi/blob/master/avahi-client/entrygroup.c#L373. 
> In this way when we call the `avahi_entry_group_add_service_strlst` 
> API, we can construct the TXT string list by calling 
> `avahi_string_list_add` in the normal order.
>
> On the other hand, the TXT passed into `AvahiServiceResolverCallback` 
> is in the reverse order, which is different from above. When a user 
> receives the TXT in the callback, the user may have to reverse the TXT 
> string list first to get the correct order.
>
> Is this a bug or by design?
>
> Also, it seems that `avahi-browse` also doesn't reverse the TXT string 
> list in its callback so that it returns the TXT record in the reversed 
> order. This can be confirmed by following commands:
>
> ```
> $ sudo avahi-publish-service test1 _test._udp 1234 k1=v1 k2=v2
> ```
>
> ```
> $ avahi-browse -rt  _test._udp
> ```
>
> Regards,
> Handa

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/avahi/attachments/20230313/3e77bb5f/attachment.htm>