What's a reliable HTTP response for ESP8266 Web Server?

CheeseNWine · September 12, 2018, 1:19pm

Hi All, I suspect this is more of a web development issue than to do with Arduino but here it is anyway... I trust you lot would have a better understanding than most...

I have an ESP8266 with a web server hosting a very simple page. The page just returns a simple JSON response. The response page seems to work very well in Edge, quite often in IE and rarely ever in Chrome, Fireforx or my android mobile.

Can you see what's wrong with the page that generates from this?

This is the page string I return:

  String htmlPage = "" +
      String("HTTP/1.1 200 OK\r\n") +
      "Content-Type: application/json\r\n" +
      "\r\n" +
      "{ ""digitalPin1Toggle"" : """ + digitalPin1Toggle +""" }\r\n";

I expect something like:

{ digitalPin1Toggle : Off }

Displays OK on Edge

On Chrome I mostly get "This site can’t be reached" and sometimes just a blank page. When I Inspect the page in Chrome, there's a console error "GET http://10.1.1.157/D1/Off net::ERR_CONNECTION_RESET 200 (OK)"

Firefox always returnd "The connection was reset".

My mobile browser sometimes displays the response page and sometimes is totally blank.

But in all cases, I know the request was received by the ESP and it responded. BTW, I also tried just a plain ordinary HTML page with the same result.

Thanks for your help...
Cheese

Juraj · September 12, 2018, 1:40pm

add "Content-length:" header and "Connection: close" header

CheeseNWine · September 13, 2018, 11:18am

Good one. Thanks Juraj! "Content-Length:" did the job. I just had to refactor the code to do the calculation.

Juraj · September 13, 2018, 11:21am

github.com

jandrassy/StreamLib/blob/master/README.md#http-data-length

# StreamLib

## Buffering and flush()

In Arduino world there was a confusion about the flush() function. Some libraries implement it to discard the incoming bytes, reading them without storing. But decades is the flush() function in C, C++, Java used in conjunction with output buffering. To not to send every small piece of data over a connection with overhead of protocol bytes like network protocols (TCP, UDP) or IC communication protocol (I2C, SPI) we need buffering. Data are collected until the buffer is full and then the collected data are send and the buffer is ready for next bytes. And the flush() functions sends the buffer even if it is not full, but we do not have more data. So buffering without the right flush() function is not possible and many arduino libraries suffer of slow communication because the authors didn't use buffering. The flush() dilemma is resolved and in Arduino core classes the flush() method is declared in Print class which is the Arduino standard interface for output streams.

This library offers a BufferedPrint class which wraps the target stream and buffers the data to be send over the target stream. Of course, do not forget to use flush() after last data printed.

The BufferedPrint doesn't call flush() on underlying target stream, because if the target stream has the wrong flush implementation, it could throw away the response of your request.

## HTTP data length

It is common practice in Arduino sketches to not to send the Content-length header with HTTP responses and POST requests. In most cases it is because when the HTTP headers are send, the size of data is not known. The browser or WebServer then doesn't know if it received all the data and waits until the connection is closed or timeout is reached. It leads to long time until the page is shown in browser or long time until a Web Server sends the response to requesting Arduino sketch.

This library offers two solutions to this problem. If the data can be prepared to a string in memory, the CStringBuilder is the way. Prepare the string and use CStringBuilder's getLength() to fill the Content-length HTTP header.

If the data to be send as response or in POST request wouldn't fit into available memory, ChunkedPrint can be used with HTTP chunked Transfer-Encoding. And ChunkedPrint is an extension of BufferedPrint so your page shows up in browser quickly and the Web Server handles your request without hesitating. 

## Decode HTTP chunked transfer encoding

This file has been truncated. show original

Topic		Replies	Views
ESP8266WebServer vs. WifiServer Networking, Protocols, and Devices	3	113	December 10, 2025
ESPAsyncWebServer send an answer Networking, Protocols, and Devices	10	1513	January 11, 2025
ESP8266 HTTP Response Time, timeout Programming	10	11591	May 6, 2021
Any HTTP request takes 2 seconds on ESP8266 Programming	5	306	June 29, 2024
ESP8266 - how to stream a response of unknown length? Programming	12	3699	May 6, 2021

What's a reliable HTTP response for ESP8266 Web Server?

Related topics