HTTP/1.1 - Transfer-Encoding: chunked - delay in the middle of response - chunked-encoding

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.