[mathieucarbou]

Summary

Fixes #500 and the other places where request processing broke when a heap allocation failed.

An Arduino String whose allocation fails is left empty, and its c_str() returns NULL on ESP32. Depending on where that happened, the library crashed, silently mis-parsed the request, corrupted the HTTP wire format, or served the wrong file.

Why

Issue #500 reported a crash in _parseReqHeader(): the Accept value was copied into a new String, the copy failed under heap pressure, and strstr(NULL, ...) hard-faulted in the async_tcp task. The same pattern existed in several other places, with different (but equally wrong) outcomes.

What changed

Header parsing (WebRequest.cpp, AsyncWebHeader.cpp)

• New AsyncWebHeader::tryParse() returns ParseStatus::{Ok,Invalid,NoMemory} so a failed name/value copy fails the request rather than silently dropping the header. A dropped Content-Length or Transfer-Encoding desynchronizes the body parser.
• Accept and Transfer-Encoding are now scanned in place — the lowercased copies are gone entirely, so the Null dereference in _parseReqHeader() when the Accept header copy fails to allocate (crash instead of rejecting the request) #500 crash cannot occur and chunked framing can no longer be silently missed.
• Failed copies into _host, _contentType and _authorization abort the request instead of handing handlers corrupt state.
• Failed header-line accumulation in _onData() and failed byte accumulation in the plain/multipart body parsers abort instead of truncating data.
• The 100 Continue reply is written straight from the literal (the String copy exceeded the small-buffer size, and an OOM one silently stalled the client).

Responses (WebResponses.cpp, AsyncWebSocket.cpp, AsyncEventSource.cpp)

• Every concat() in _assembleHead() is checked; on OOM the buffer is emptied and all four _respond() callers close the connection instead of writing a truncated head.
• AsyncWebSocketResponse sets RESPONSE_FAILED when it cannot build Sec-WebSocket-Accept, and _sourceValid() reflects it, so the upgrade is refused instead of completing with a garbage accept header.

Allocation helpers

• beginResponse*(), AsyncStaticWebHandler and AsyncEventSource use std::nothrow, making their existing null checks live instead of unreachable (plain new aborts the device on OOM). send() / _send() now handle a null response.
• generateBasicHash() and the WebSocket printf helpers use malloc where the null checks were dead code.

Static file handler (WebHandlers.cpp)

• If the request path cannot be built, canHandle() returns false so the request falls through to another handler / 404 instead of serving the default or a wrong file.

Known limitation (not addressed here)

std::list::emplace_back (headers, params), std::vector, std::make_shared (WebSocket message buffers) and the cbuf allocated inside AsyncResponseStream still use throwing-new, so an OOM there aborts the device. Fixing that needs custom allocators/containers and is out of scope for this change.

Validation

• Builds: arduino-3, esp8266, raspberrypi, libretiny, arduino-2-esp-idf-log (core 2.x), no-json, regex, no-chunk-inflight, latest-asynctcp — all pass.
  • Note: the arduino-2 env itself fails before compiling any source because PlatformIO no longer serves the pinned tool-esptoolpy@^5.3.0; this happens on unmodified main too. The arduino-2-esp-idf-log env covers the same core.
• cpplint with the CI filter set: 0 errors. codespell: clean. Formatted with the pinned clang-format 18.1.3.

Opened as a draft for review.

[mathieucarbou]

@willmmiles : this is a starting point, not fully tested yet.
I intend to strip the comments out (some comments are not useful).
Feel free to add more commits, cleanups, etc. We can work together on this one if you want to or see things missing.
Thanks!

[willmmiles]

Apart from String, we'll also need to consider what happens when std classes suffer allocation failures. On some platforms, they'll throw std::bad_alloc; on platforms using -fno-exceptions (ESP8266, RP2040), the device will just panic.

If we want to support handling allocation failure on platforms with -fno-exceptions, we'll need to replace all uses of std::make_shared, std::vector and std::list at a minimum.

[mathieucarbou]

If we want to support handling allocation failure on platforms with -fno-exceptions, we'll need to replace all uses of std::make_shared, std::vector and std::list at a minimum.

That’s true, but maybe we can do it in 2 pass ?
Replacing std is a bigger change.

[willmmiles]

If we want to support handling allocation failure on platforms with -fno-exceptions, we'll need to replace all uses of std::make_shared, std::vector and std::list at a minimum.

That’s true, but maybe we can do it in 2 pass ? Replacing std is a bigger change.

For sure. I think we should spin out a separate little library to host those replacements - I think they've got wider utility to support safe and efficient C++ usage across the embedded development world. (I'm honestly somewhat disappointed in the internet that I wasn't able to find such a collection already!)

[mathieucarbou]

@willmmiles : except for the last commit that I asked copilot to remove, you you approve these changes ?

[mathieucarbou]

@willmmiles : except for the last commit that I asked copilot to remove, you you approve these changes ?

reminder ;-)

[willmmiles]

Why forward declare this when the definition is ~20 lines down?

[mathieucarbou]

because ParseResult is inside AsyncWebHeader (static ParseResult tryParse(const char *data);) and contains the resulting AsyncWebHeader.

[me-no-dev]

LGTM though the PR is quite big and seems fixing more than one thing, so it is possible that I missed something

[mathieucarbou]

LGTM though the PR is quite big and seems fixing more than one thing, so it is possible that I missed something

I don't think it fixes more than needed: handling allocation failures requires to make callers and eventually client aware of them (503 or return codes or status). So yes the changes are more than just the core code doing allocations.

[mathieucarbou]

@willmmiles : Can I let you check again please ? If the PR is good for you, then you can merge. Thanks :-)