Support provider "Ionos DynDns"

[Somebodyisnobody]

The ionos dyndns-service (documented here) returns no body but a HTTP status code 200. This causes inadyn to fail because a response body with the text "good" is expected. Inadyn crashes in the init service and will not restart on debian systems.

[troglobit]

For future readers, the text above is a bit misleading, In-a-dyn does not have any support for Ionos yet, so the fact that it crashes is to be expected.

Contributions are welcome.

[Somebodyisnobody]

@troglobit Thank you. We can generalize this: If we use the "custom" provider inadyn should not expect to get a response body back and go into a compatibility mode where it only watches the http response status code.

I am no C#-pro (honestly have no clue) but shouldn't it be a change here only?:

inadyn/plugins/common.c

Lines 51 to 64 in f3c9046

	int common_response(http_trans_t *trans, ddns_info_t *info, ddns_alias_t *alias)
	{
	char *body = trans->rsp_body;
	(void)info;
	(void)alias;
	DO(http_status_valid(trans->status));
	if (strstr(body, "good") || strstr(body, "nochg") || strstr(body, "OK"))
	return 0;
	if (strstr(body, "dnserr") || strstr(body, "911") || strstr(body, "abuse"))
	return RC_DDNS_RSP_RETRY_LATER;

Change L60 to:

if (string.IsNullOrEmpty(body) || strstr(body, "good") || strstr(body, "nochg")  || strstr(body, "OK") || body == null)
		return 0;

[troglobit]

The reporter of this issue is again trying to imply there's a bug in In-a-dyn. This time in the "custom" provider functionality, which has for over 15 years worked perfectly! Of course, there is nothing wrong with the way In-a-dyn works, it's modeled after dyn.com and other DDNS providers mimicking their API. But if you do not mimic this API, then sure, In-a-dyn will not work, in particular not using the "custom" provider -- this is exactly why you need a dedicated C plugin for your provider. (In-a-dyn is not written in C#, only plain C)

[Somebodyisnobody]

I never said there is a bug. I don't see a bug in inadyn. I just suggested a compatibility mode for APIs which do not communicate properly.

The title of the issue also states that this is a feature request for supporting a provider which is de facto currently not supported (Ionos). Otherwise the title would be something like "Provider Ionos not implemented correctly"