Hi Kelson, You're misreading the code, "5" is the numeric value of the option in the enum, not the actual default limit. The default limit is indeed zero as per the documentation (and a limit for zero means 'unlimited').
I think your suggestion to check against X-Forwarded-For is interesting, but I wonder if in that case it would not be better/simpler to simply let the reverse proxy do this check? At least I expected that to be the case, and I think _if_ we implemented an X-Forwarded-For based check, we'd need a new option, new data structure, and it'd also imply a (minor) additional performance hit. So really the question is: if you're behind a reverse proxy, why not configure the reverse proxy to limit the number of connections per IP? Happy hacking! Christian On 2/6/22 11:54 AM, Emmanuel Engelhart wrote: > Hi, > > At Kiwix, our most critical use case of libmicrohttpd is behind a > reverse-proxy. One of the reason is to be able to easily provide a HTTPS > end-point. With the success of HTTPS, I suspect that this might even be > meanwhile a common use-case for libmicrohttpd. > > Because this service has a high throughput, we keep improving the > overall performance and better secure the stability of the service. This > is why we consider using MHD_OPTION_PER_IP_CONNECTION_LIMIT to better > handle how the connections are distributed. > > My first remark/question is about microhttpd.h. It is written in the > comment "The default is zero", but actually the code stays that > "MHD_OPTION_PER_IP_CONNECTION_LIMIT = 5". I find it pretty confusing to > understand what is the default behaviour if nothing is specified! > > The second point is regarding the behaviour if the daemon is behind a > reverse-proxy. From what I see in the code, in such a scenario the > reverse-proxy IP will be interpreted as the client IP, right (which > means that it won't probably behave like expected)? If "yes", have you > consider to check first > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For? > In such a case the daemon would always behave properly IMO. > > Regards > Kelson >
