-
Notifications
You must be signed in to change notification settings - Fork 385
Description
I have an inputs.conf stanza for accepting data over a UDP port. It was created with a restrictToHost value, so its name is of the form udp://<host>:<port>. But when I update the properties, its name changes to udp://<host>:<host>:<port>, where both instances of <host> are the same.
Digging around pointed to the comment on client.Input.update(). If restrictToHost is set, it is sent with every update request in order to preserve compatibility with 5.0.0 and 5.0.1. The comment also notes that in 5.0.2 and higher, you cannot change restrictToHost once it's set, so this resend of restrictToHost isn't a problem.
When the kind is "tcp/raw" ("tcp" in the SDK), this is true: attempting to set restrictToHost to the same value it was before just does nothing, and attempting to change it prompts it to state that restrictToHost cannot be updated. However, when the kind is "udp", it respects the new restrictToHost value. It will only accept one additional restrictToHost value: trying to add a third generates an error that it's not a valid port. Some testing with the REST API has shown that the second restrictToHost value is inserted before the old one.
To reproduce this using the SDK:
stanza = service.inputs.create("1234", "udp", restrictToHost="foo")
stanza.update(connection_host="dns")
Or the REST API:
curl -k -u admin:pass https://localhost:8089/services/data/inputs/udp -d name=1234 -d restrictToHost=foo
curl -k -u admin:pass https://localhost:8089/services/data/inputs/udp/foo%3A1234 -d restrictToHost=foo -d connection_host=dns
Both will produce the following stanza in inputs.conf:
[udp://foo:foo:1234]
connection_host = dns