libmicrohttpd
[Top][All Lists]
Advanced

[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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]