libesphttpd Kconfig opinions

[cmorgan]

Hello.

I'm using libesphttpd with https support.

I have a system where the esp32 is in both station and AP mode. On the AP interface I'm using a captive portal that responds to DNS requests with the IP of the esp32, redirecting all traffic to the esp23.

When libesphttpd is operating in https mode the the crypto processing for https makes this effectively a DDOS of the esp32. The connecting computer attempts to reestablish connections for web browser tabs, check sites to validate whether the AP provides Internet connectivity etc and all of these requests hit the web server. Assuming that the crypto processing on the esp32 is already about as fast as it can get (I've reenabled hardware crypto and am using a pretty recent esp-idf), the next best approach seemed to be to host http on the AP and only host https on the public wifi interface.


That brings me to the Kconfig question.

Currently libesphttpd provides a helpful way to point at web pages, images, files etc that are embedded into the flash during the build. You simply go into the Kconfig menu for esphttpd and point it at a directory where these files will be pulled in.

The issue is that the current Kconfig setup assumes a single instance of the libesphttpd server and a single set of files that are pulled in for the filesystem.

A few things came to mind:
- A libesphttpd instance per interface (is it even possible to do dynamic instances with Kconfig or would it require providing some options for the range of possible interfaces?)
- A way to have more than one generic libesphttpd instance where the user would then associate with the network interface at runtime
- A single libesphttpd configuration but with a way to have multiple embedded filesystem instances. This would let someone create multiple libesphttpd instances at runtime and then associate each one with a separate filesystem.
- Am I missing something with the https crypto load issue and trying to solve the wrong issue?

Thoughts?

Chris

[WiFive]

Instead of captive portal catch-all you could have a specific dns name to access the device

[cmorgan]

Instead of captive portal catch-all you could have a specific dns name to access the device

That's actually not a bad idea. The goal is to simplify the initial configuration. If it were as simple as:

- Connect to AP
- Browse to https://configure (or something like that)

That could work....


Any thoughts on whether another user would want multiple web servers with different sets of pages between different interfaces?