HTTP / 1.1-传输编码：分块-响应中间的延迟

Question

I am using WINC1500 WiFi (with Arduino) to connect to a server (https) and to send some API requests. In the header I send:

POST /api/myapi.php HTTP/1.1
Host: myserver.com
Accept: application/json, text/javascript, */*; q=0.01
Content-Type: application/x-www-form-urlencoded; charset=iso-8859-1
Connection: keep-alive
Content-Length: 10

my_content

The server response is ok, something like this:

HTTP/1.1 200 OK
Date: Tue, 03 Sep 2019 16:31:14 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/json

18f
BlaBlaBla.... (399 chars = 18f in hexa)
0

The problem is that, after the first chunk, there is a delay in waiting for the terminating chunk. THe last chunk is an empty one. This is an example to understand it:

HTTP/1.1 200 OK 
Content-Type: text/plain 
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n 
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n 
\r\n

Ok... Let's look at the time line:

19:31:13.685 -> connecting...
19:31:14.325 -> posting...
19:31:15.745 -> end posting...
19:31:15.864 ->     HTTP/1.1 200 OK
19:31:15.864 ->     Date: Tue, 03 Sep 2019 16:31:14 GMT
19:31:15.864 ->     Server: Apache
19:31:15.864 ->     Expires: Thu, 19 Nov 1981 08:52:00 GMT
19:31:15.864 ->     Cache-Control: no-store, no-cache, must-revalidate
19:31:15.864 ->     Pragma: no-cache
19:31:15.904 ->     Keep-Alive: timeout=5, max=100
19:31:15.904 ->     Connection: Keep-Alive
19:31:15.904 ->     Transfer-Encoding: chunked
19:31:15.904 ->     Content-Type: application/json
19:31:15.904 ->     
19:31:15.904 -> waitingChunkLength: 18f
19:31:15.904 -> 399
19:31:15.945 -> waitingChunk: BlaBlaBla.... (399 chars)
19:31:20.875 -> waitingChunkLength: 0
19:31:20.875 -> 0
19:31:20.875 -> waitingChunkTrailer: 
19:31:20.875 -> Done...
Connection closed

After receiving the first and only chunk, there is a huge delay before receiving the last (terminating) chunk. Actually, the last chunk is send just before the connection to be closed by server. I believe that is happening because of the idle time. There are 5 seconds of inactivity, so the server must close the connection.

I try to send a message ("OK") to server just after receiving the first chunk. In this case, the server is responding immediately, but is closing the connection (I believe because of inadequate message):

19:45:43.818 -> connecting...
19:45:44.688 -> posting...
19:45:46.207 -> end posting...
19:45:46.322 ->     HTTP/1.1 200 OK
19:45:46.322 ->     Date: Tue, 03 Sep 2019 16:45:44 GMT
19:45:46.322 ->     Server: Apache
19:45:46.322 ->     Expires: Thu, 19 Nov 1981 08:52:00 GMT
19:45:46.322 ->     Cache-Control: no-store, no-cache, must-revalidate
19:45:46.322 ->     Pragma: no-cache
19:45:46.322 ->     Keep-Alive: timeout=5, max=100
19:45:46.358 ->     Connection: Keep-Alive
19:45:46.358 ->     Transfer-Encoding: chunked
19:45:46.358 ->     Content-Type: application/json
19:45:46.358 ->     
19:45:46.358 -> 
19:45:46.358 -> waitingChunkLength: 18f
19:45:46.358 -> 399
19:45:46.398 -> waitingChunk: BlaBlaBla.... (399 chars)
19:45:46.517 -> waitingChunkLength: 0
19:45:46.517 -> 0
19:45:46.517 -> waitingChunkTrailer: 
19:45:46.517 -> Done...
Connection closed

I need to know where is the problem. Should I send a special message to server after each chunk? Because of this behaviour I cannot take advantage of "Keep-alive" session.

Answer 1

After changing firmware a couple of times without success, I go back to the code and try different things. The problem seems to be last line in POST action:

client.print("Content-Length: ");
client.println(10);
client.println();
client.println("my_content");

This last line should be:

client.print("my_content");

... println appends a carriage return character (ASCII 13, or '\\r') and a newline character (ASCII 10, or '\\n') after text. So, this extra (unexpected) characters give me so much troubles those days. Hope this solve your problems too.