ESPAsyncWebServer 2.2.0 + features #3828
Conversation
These were mostly PROGMEM already, but every little bit helps.
Rather than relying on the exception handler, indicate the __FlashStringHelper type so the correct String constructor is used.
Eliminate the extra indirection and allocate shared buffers directly.
No need to filter or look up content type, just pitch it over the wall. Also fixes .gz'd content processing.
There were three problems here:
- AsyncWebServer is going to copy to a heap buffer anyways, so we might
as well just pass it one it can use
- The buffer size estimate was wrong -- we need 9 bytes per pixel
("RRGGBB",), so the buffer could overflow, and it was not
considering the extra 2D requirements
- On ESP8266, the stack allocation was overflowing the stack, causing
corruption and crashes.
|
@willmmiles is this ready to be merged? I will blindly believe you. 😄 |
|
I think so, but the whole point of a PR is to get a second pair of eyes in case I made some easy to spot mistake! The changes are pretty shallow, with the intent to make it easier to review - it's probably easier to go through them one commit at a time. There are a couple places where the code could maybe be cleaner at the expense of the patches being harder to follow. One example is factoring out the now-duplicate names in wled_server. I had planned to send a second PR with cleanup later after you'd checked that the logic was sound. The last commit (5f2480c) is probably the most critical, as it both fixes an actual buffer overflow when |
Use the CONTENT_TYPEs exported by AsyncWebServer directly.
Allocate the serialization buffer size at the required length, rather than always allocating the maximum size.
|
Code inspection reveals no discrepancies but I have not tested it yet. |
|
I went ahead and did those two code quality improvements. Might as well save on the testing effort! |
2 participants
Update to ESPAsyncWebServer 2.2.0 and leverage the new features.