[GH-ISSUE #1594] handleParam() - memory issue? (Blank Page in browser) #1360

New issue

Open

opened 2026-02-28 01:29:45 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 01:29:45 +03:00

Owner

Originally created by @realA10001986 on GitHub (Apr 21, 2023).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1594

I am maintaining a rather large ESP32-based project using 82 WifiManagerParameters (including graphical enhancements cramped into WifiManagerParameters as pure HTML) and logo graphics in shape of a base64-blob in a custom head element. The Setup page (xxx/param) is around 35k when sent to the browser, around 10k of which is the custom header.

Recently, I noticed that I sometimes get a blank page in the browser, instead of my Setup page. Looking at my code, whose only change was the addition of another 2 WifiManagerParameters, I found no issue.

WiFiManager, in handleParam(), builds the page String by concatenating Strings, in my case lots of Strings. The big header is one of the first Strings, to which 82 and more shorter ones are appended. Assuming the concatenating process involves allocating a new memory area the combined size of the two Strings to be joined, my relatively huge header probably causes massive heap fragmentation when repeatedly appending other Strings to it. Despite the page String being built correctly (proven by a Serial printout before and after "HTTPSend(page)" in handleParam(), all the browser got was a blank page, with a Content-Length of 0.

I assume that somewhere down the line, there is a memory issue (possibly caused by fragmentation) which leads to the HTTP transfer to fail. Similar problem: https://github.com/espressif/arduino-esp32/issues/5802

One of the easiest remedies would be to first concatenate the parameters and the footer stuff, and only as a last step to concatenate the header with the rest. This would keep fragmentation better in check (and I failed to reproduce the problem after this little change). Another way, as outlined in the issue linked to above, would be to have "HTTPSend()" look at the size of the document, and send it in 10k chunks if it is beyond this size.

Originally created by @realA10001986 on GitHub (Apr 21, 2023). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1594 I am maintaining a rather large ESP32-based project using 82 WifiManagerParameters (including graphical enhancements cramped into WifiManagerParameters as pure HTML) and logo graphics in shape of a base64-blob in a custom head element. The Setup page (xxx/param) is around 35k when sent to the browser, around 10k of which is the custom header. Recently, I noticed that I sometimes get a blank page in the browser, instead of my Setup page. Looking at my code, whose only change was the addition of another 2 WifiManagerParameters, I found no issue. WiFiManager, in handleParam(), builds the page String by concatenating Strings, in my case lots of Strings. The big header is one of the first Strings, to which 82 and more shorter ones are appended. Assuming the concatenating process involves allocating a new memory area the combined size of the two Strings to be joined, my relatively huge header probably causes massive heap fragmentation when repeatedly appending other Strings to it. Despite the page String being built correctly (proven by a Serial printout before and after "HTTPSend(page)" in handleParam(), all the browser got was a blank page, with a Content-Length of 0. I assume that somewhere down the line, there is a memory issue (possibly caused by fragmentation) which leads to the HTTP transfer to fail. Similar problem: https://github.com/espressif/arduino-esp32/issues/5802 One of the easiest remedies would be to first concatenate the parameters and the footer stuff, and only as a last step to concatenate the header with the rest. This would keep fragmentation better in check (and I failed to reproduce the problem after this little change). Another way, as outlined in the issue linked to above, would be to have "HTTPSend()" look at the size of the document, and send it in 10k chunks if it is beyond this size.

kerem commented

2026-02-28 01:29:46 +03:00

Author

Owner

@georgevbsantiago commented on GitHub (Apr 21, 2023):

I came across a similar problem when including logo (base64 image) larger than 4kb
https://github.com/tzapu/WiFiManager/issues/1541

@georgevbsantiago commented on GitHub (Apr 21, 2023): I came across a similar problem when including logo (base64 image) larger than 4kb https://github.com/tzapu/WiFiManager/issues/1541

kerem commented

2026-02-28 01:29:46 +03:00

Author

Owner

@tablatronix commented on GitHub (Apr 23, 2023):

#518
Yeah I need some solution, preallocate page size to avoid fragmentation, or some other buffer method to flush out

@tablatronix commented on GitHub (Apr 23, 2023): #518 Yeah I need some solution, preallocate page size to avoid fragmentation, or some other buffer method to flush out

kerem commented

2026-02-28 01:29:46 +03:00

Author

Owner

@timr49 commented on GitHub (Jun 29, 2025):

Hi @realA10001986

WiFiManager, in handleParam(), builds the page String by concatenating Strings, in my case lots of Strings. The big header is one of the first Strings, to which 82 and more shorter ones are appended. Assuming the concatenating process involves allocating a new memory area the combined size of the two Strings to be joined, my relatively huge header probably causes massive heap fragmentation when repeatedly appending other Strings to it. Despite the page String being built correctly (proven by a Serial printout before and after "HTTPSend(page)" in handleParam(), all the browser got was a blank page, with a Content-Length of 0.

I assume that somewhere down the line, there is a memory issue (possibly caused by fragmentation) which leads to the HTTP transfer to fail. Similar problem: espressif/arduino-esp32#5802

It is likely that even though you built a correct string, there was insufficient memory remaining for the web server to do its thing.

One of the easiest remedies would be to first concatenate the parameters and the footer stuff, and only as a last step to concatenate the header with the rest. This would keep fragmentation better in check (and I failed to reproduce the problem after this little change). Another way, as outlined in the issue linked to above, would be to have "HTTPSend()" look at the size of the document, and send it in 10k chunks if it is beyond this size.

Another remedy is to build and send the page chunk by chunk so that you never build large strings in the first place.
If it helps, I developed an enhancement to WiFiManager that does this. You can get it from branch Chunking in the repo https://github.com/timr49/WiFiManager
It is described in https://github.com/timr49/WiFiManager/blob/Chunking/PAGE.md

@timr49 commented on GitHub (Jun 29, 2025): Hi @realA10001986 > WiFiManager, in handleParam(), builds the page String by concatenating Strings, in my case lots of Strings. The big header is one of the first Strings, to which 82 and more shorter ones are appended. Assuming the concatenating process involves allocating a new memory area the combined size of the two Strings to be joined, my relatively huge header probably causes massive heap fragmentation when repeatedly appending other Strings to it. Despite the page String being built correctly (proven by a Serial printout before and after "HTTPSend(page)" in handleParam(), all the browser got was a blank page, with a Content-Length of 0. > > I assume that somewhere down the line, there is a memory issue (possibly caused by fragmentation) which leads to the HTTP transfer to fail. Similar problem: [espressif/arduino-esp32#5802](https://github.com/espressif/arduino-esp32/issues/5802) It is likely that even though you built a correct string, there was insufficient memory remaining for the web server to do its thing. > One of the easiest remedies would be to first concatenate the parameters and the footer stuff, and only as a last step to concatenate the header with the rest. This would keep fragmentation better in check (and I failed to reproduce the problem after this little change). Another way, as outlined in the issue linked to above, would be to have "HTTPSend()" look at the size of the document, and send it in 10k chunks if it is beyond this size. Another remedy is to build and send the page chunk by chunk so that you never build large strings in the first place. If it helps, I developed an enhancement to WiFiManager that does this. You can get it from branch Chunking in the repo https://github.com/timr49/WiFiManager It is described in https://github.com/timr49/WiFiManager/blob/Chunking/PAGE.md