promhttp: promhttp_start_daemon does not accept MHD options

[GerMalaz]

MHD_start_daemon() does accept a variable argument list with MHD options.
promhttp_start_daemon() does not, always passes an empty list of options.

[jelmd]

Yes, this is intentional because the implementation (promhttp_handler()) does not use it at all, so there is no need to pass anything or clutter the arg list of related function(s).

Moreover, promhttp/** is not part of the library/API (only prom/** gets into libprom); it is intentionally kept as a minimal quick start example so people can simply copy and modify it for their own app as needed. So if someone modifies or replaces the request handler implementation to use any passed arguments, it naturally follows that promhttp_start_daemon() may need to be adapted accordingly as well, i.e. accept and pass them to MHD_start_daemon(), too.

Did I miss something?

[GerMalaz]

The use case I am missing is to listen locally, rather than globally.
MHD can do this via an option, MHD_OPTION_SOCK_ADDR,
but there no way for libprom users to do it.

Modifying promhttp_start_daemon() requires passing MHD_OPTION_END even if you have no options.

But , not necessarily needs to be changed.
There is a MHD_start_daemon_va() function, MHD_start_daemon() is basically a wrapper around it.
Please check #4 , creates a promhttp_start_daemon_va() similarly defined, which calls MHD_start_daemon_va().
So, if you need/want options, you can use this function promhttp_start_daemon_va() instead.
MHD_OPTION_END is needed when calling this function, but then, option list is expected here.
And promhttp_start_daemon() is unchanged.

[jelmd]

The use case I am missing is to listen locally, rather than globally. MHD can do this via an option, MHD_OPTION_SOCK_ADDR, but there no way for libprom users to do it.

This seems to be a source of confusion: promhttp_start_daemon() is not part of libprom, but of libpromhttp. The latter is only a helper intended for testing and very simple use cases. In most real scenarios, users will need to implement their own http_handler, which makes libpromhttp mostly unnecessary overhead.

Therefore, yes - promhttp/src/promhttp.c would arguably fit better under examples. However, for historical reasons, testing purposes, and because it may still help with simple "quick start" projects, it has been kept as a separate component.

Modifying promhttp_start_daemon() requires passing MHD_OPTION_END even if you have no options.

But promhttp_start_daemon(), not necessarily needs to be changed. There is a MHD_start_daemon_va() function, MHD_start_daemon() is basically a wrapper around it. Please check #4 , creates a promhttp_start_daemon_va() similarly defined, which calls MHD_start_daemon_va(). So, if you need/want options, you can use this function promhttp_start_daemon_va() instead.

Yes, but I’m still not fully convinced this is the right approach. libprom intentionally does not depend on libmicrohttpd, and extending libpromhttp further might encourage package maintainers to bundle it with libprom, thereby introducing an unwanted dependency.

Perhaps it would be better to explicitly recommend that libprom users copy promhttp/src/promhttp.c into their own project and adapt it as needed. Than adding the _va variant should not hurt that much ;-)

[GerMalaz]

I see, thank you.
But while libprom does not depend on libmicrohttpd, libpromhttp DOES depends on it, and pulls it in.