me-no-dev / ESPAsyncWebServer

Async Web Server for ESP8266 and ESP32
3.61k stars 1.17k forks source link

Garbled HTML Markup Received By Browser #1222

Open DiverBW opened 1 year ago

DiverBW commented 1 year ago

In the callback function for the HTTP GET, I am generating the HTML markup into a buffer then transmit that buffer back with the HTTP 200 response via calling the request->send method.

I am writing the markup out to the Serial log and it looks fine. But the page has garbled text in the browser. I use the browsers "view source" to look at the HTML source, and can see that it is indeed garbled.

It seems as if the network transmission from my ESP32 wifi is getting garbled. The wifi router and the PC where I am running the browser are both on the same local network, hardwired.

What is causing this data corruption during transmission?

Here are some of the pertinent lines of source code from my ESP32 application:

During initialization, I register the callback function for the root page /:

m_webServer.on("/", HTTP_GET, HttpGet_StatusPage);

This is the entirety of my callback function:

void HttpGet_StatusPage(AsyncWebServerRequest request) { const char pMarkup = Markup_StatusPage(); request->send(200, "text/html", pMarkup); }

The method Markup_StatusPage() is where the HTML markup is generated. It is

define MARKUP_BUFFER_SIZE 2000

char x_markupBuffer[MARKUP_BUFFER_SIZE];

const char* BWArduinoApp::Markup_StatusPage() { .... code that writes HTML content into x_markupBuffer. Serial.println(x_markupBuffer); // Markup written out here is fine! return x_markupBuffer; }

Any ideas?

DiverBW commented 1 year ago

OK, I found the problem. I had a suspicion that the corrupted data was due to some sort of memory corruption/overlap/misuse. I thought that declaring the x_markupBuffer space in global space meant that the memory space was statically allocated and would be reliable. But I was not 100% of this assumption, so I decided to test that assumption.

I changed the place where I declared x_markupBuffer: I moved it so that it was a private data member of my class. This fixed the problem. Apparently my assumption was wrong...

I'd be curious to know more about why this fixed the problem if anyone cares to explain, but otherwise, consider this problem solved.

On Tue, Oct 18, 2022 at 6:25 PM DiverBW @.***> wrote:

In the callback function for the HTTP GET, I am generating the HTML markup into a buffer then transmit that buffer back with the HTTP 200 response via calling the request->send method.

I am writing the markup out to the Serial log and it looks fine. But the page has garbled text in the browser. I use the browsers "view source" to look at the HTML source, and can see that it is indeed garbled.

It seems as if the network transmission from my ESP32 wifi is getting garbled. The wifi router and the PC where I am running the browser are both on the same local network, hardwired.

What is causing this data corruption during transmission?

Here are some of the pertinent lines of source code from my ESP32 application:

During initialization, I register the callback function for the root page /:

m_webServer.on("/", HTTP_GET, HttpGet_StatusPage);

This is the entirety of my callback function:

void HttpGet_StatusPage(AsyncWebServerRequest

request) { const char pMarkup = Markup_StatusPage(); request->send(200, "text/html", pMarkup); }

The method Markup_StatusPage() is where the HTML markup is generated. It is

define MARKUP_BUFFER_SIZE 2000

char x_markupBuffer[MARKUP_BUFFER_SIZE];

const char* BWArduinoApp::Markup_StatusPage() { .... code that writes HTML content into x_markupBuffer. Serial.println(x_markupBuffer); // Markup written out here is fine! return x_markupBuffer; }

Any ideas?

— Reply to this email directly, view it on GitHub https://github.com/me-no-dev/ESPAsyncWebServer/issues/1222, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADI5PRK6Q76TLGBFHAU6KXLWD4PTZANCNFSM6AAAAAARIQ6NE4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

stale[bot] commented 1 year ago

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.