[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] MHD_OPTION_PER_IP_CONNECTION_LIMIT behaviour behind
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] MHD_OPTION_PER_IP_CONNECTION_LIMIT behaviour behind a reverse proxy |
Date: |
Sun, 6 Feb 2022 12:39:29 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
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
>