Non-blocking HTTP requests for ESP-IDF
- Dominant language
- No language data
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
The current `http_request` component blocks the main loop while the connection is set up (reading body in `loop()` is possible.)
Claude's take on this is below, I believe it's a decent summary. The additional task is a heavyweight solution, re-implementing using sockets and select() is a big job with significant risks. I did not see anything in newer IDF that changes much, and testing the "async" connect does still block on the initial handshake.
## From Claude.ai
The key is using esp_http_client_perform_async() instead of the blocking esp_http_client_perform(). However, there's an important detail about connection handling:
Non-blocking Connection Setup
For truly non-blocking connection establishment, you need to:
Set the client to non-blocking mode using esp_http_client_set_timeout_ms() with a timeout of 0, or configure it during initialization
Use ESP_HTTP_CLIENT_NON_BLOCKING configuration option (though this isn't always sufficient by itself)
Better Approach: Event-driven with esp_http_client_perform_async()
The async API is designed for this use case:
```c
esp_http_client_config_t config = {
.url = "http://example.com",
.event_handler = http_event_handler,
.timeout_ms = 5000,
};
esp_http_client_handle_t client = esp_http_client_init(&config);
// This returns immediately and continues in background
esp_err_t err = esp_http_client_perform_async(client);
```
However, even with perform_async(), the initial TCP connection and TLS handshake may still block depending on the ESP-IDF version.
Most Reliable Non-blocking Solution
For complete non-blocking behavior including connection setup, consider:
* Run HTTP requests in a separate task - Let connection blocking happen in a dedicated task
* Use the underlying socket APIs with non-blocking sockets and select()/poll()
* Check ESP-IDF version - Newer versions (5.x+) have better async support
The separate task approach is most common in ESP32 applications since it keeps your main application responsive while HTTP operations happen in the background.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.