01 Overview

Runs an HTTP server on an ESP32 that is already connected to Wi-Fi. The device's IP address can be opened in a browser to access a configuration page. Suitable for LAN-based device debugging, parameter changes, and status monitoring.

Use when: engineer debug, local switch control, provisioning portal (SoftAP mode), production line batch configuration.

Skip when: public internet exposure without authentication and TLS, high concurrency, or HTTPS requirement.

Essence: This is a lightweight embedded web server based on the esp_http_server component, consuming minimal resources, ideal for resource-constrained MCUs.

Difference from cloud: It does not rely on external servers; all logic is local, providing fast response but not accessible from the internet without port forwarding or tunneling.

02 Hardware

• No extra parts: This example only requires an ESP32 development board; no external sensors or actuators are needed.
• Wi-Fi prerequisite: Ensure Station or SoftAP mode is properly connected; otherwise, the HTTP service cannot be accessed.
• RAM consideration: Each concurrent connection consumes about 3-4KB of RAM. If serving multiple browsers, reserve enough memory based on the number of connections.
• Flash consideration: If the web page content is large, store it in SPI Flash or a file system (e.g., SPIFFS) to avoid consuming RAM.
• Power: In SoftAP mode, Wi-Fi transmission power is higher; ensure a stable power supply.
• Layout: For productization, consider antenna layout and RF interference, but this example does not involve that.

03 Software flow

1. Initialize Wi-Fi: Connect to a router (Station) or create an access point (SoftAP), and wait for an IP address.

2. Start HTTP server: Call esp_http_server_start() to create a server instance, configuring the port (default 80) and maximum number of connections.

3. Register URI handlers: Use httpd_register_uri_handler() to register callbacks for HTTP methods (GET/POST), e.g., root path '/' returns an HTML page.

4. Handle requests: In the callback, parse URL parameters or request body, perform actions (e.g., read/modify parameters), and return an HTTP response (text, JSON, or redirect).

5. Persist parameters: Write modified parameters to NVS (non-volatile storage) to ensure they survive a reboot.

6. Error handling: Check for server start failures, memory exhaustion, etc., and retry or log errors appropriately.

7. Security enhancements (for production): Add basic authentication, CSRF protection, input validation, etc., to avoid vulnerabilities.

04 Core points

• A LAN page is not a cloud API: Do not expose the LAN configuration page to the public internet; it is vulnerable to attacks.
• Do not ship debug pages on the public internet: Production firmware should remove or disable debug interfaces.
• Custom work: Configuration portal, access control, NVS binding, custom page styling.
• Mind HTTP methods: Use GET for reads and POST for modifications; avoid sending sensitive data in URLs.
• RAM limits: Do not send large pages at once; use chunked transfer or asynchronous processing.
• Do not copy HTTP implementations from other chips: ESP32's esp_http_server is asynchronous and event-driven, unlike blocking servers on other platforms (e.g., Linux).