Socket error on mg_http_reply

[rtphilipson]

I'm implementing a http reqest "GET" method response by creating a very large buffer containing a bunch of XML. and using the mg_http_reply function;

            configData[fileSize] = 0;
            mg_http_reply(c, 200, "Content-Type: application/xml; charset=UTF-8\r\n", "%s\n", configData );

I allocate a buffer of size fileSize+1 and then add the null to make sure it's null terminated before calling mg_http_reply. The config data buffer itself is about 200 Kbytes

When using curl to test, I get the entire XML buffer but then the server returns a socket error near the end. The socket error is coming from this section of code;

for (c = mgr->conns; c != NULL; c = c->next) {
if (FD(c) != INVALID_SOCKET && FD_ISSET(FD(c), &eset)) {
mg_error(c, "socket error");
} else {
c->is_readable = FD(c) != INVALID_SOCKET && FD_ISSET(FD(c), &rset);
c->is_writable = FD(c) != INVALID_SOCKET && FD_ISSET(FD(c), &wset);
if (mg_tls_pending(c) > 0) c->is_readable = 1;
}
}

in the mg_iotest() function in sock.c.

I get the entire buffer in the response and the web server doesn't crash. So I'm not even sure I should be worried about it but it concerns me that I don't know what's going on. I have a similar query endpoint that returns a much smaller buffer and I don't get the error. It takes about 30 seconds for the response to happen so maybe there is a timeout of some sort?

[scaprile]

Please provide more information, you might be running out of heap/stack; works OK for me with latest on Linux.
Do you have other actions going on ? Did you sniff your network ?

Environment

• mongoose version: X.Y
• Compiler/IDE and SDK: ZZZ version X.Y
• Target hardware/board: ?
• Connectivity chip/module: ?

[rtphilipson]

This may sound stupid, but I didn't even think to sniff since I was getting the entire response. As it turned out, the way I was doing it was accidently appending a 404 error response at the end of it which seems to have been causing the error (but I think it was happening after the completed response, so curl didn't see it. Not only did fixing the logic get rid of the socket error. Now the configuration information comes back in just a few seconds. Thanks!