Error: “No Content-Length header AND not a chunked response. Assuming no response body.”
The following error was received from a call to Rest.FullRequestSb:
ChilkatLog: FullRequestSb: DllDate: Mar 23 2022 ChilkatVersion: 184.108.40.206 Architecture: Little Endian; 64-bit VerboseLogging: 0 uriPath: ... fullRequestBody: autoReconnect: 1 Sending request with body... sendReqBody: ... --sendReqBody Sent request. fullRequestGetResponse: Reading response header... responseStatusCode: 200 Reading response body ... readResponseBody: No Content-Length header AND not a chunked response. Assuming no response body. --readResponseBody --fullRequestGetResponse --fullRequestBody Success. --FullRequestSb --ChilkatLog
If an HTTP server responds with no Content-Length header, and the response is not a “chunked” response, then there is no way for Chilkat (or any other HTTP client) to know when the full HTTP response has been received.
If the server included the “Connection: close” response header, then Chilkat will read the response until the server closes the connection.
In the above case, no “Connection: close” header was present in the HTTP response, and thus Chilkat has no recourse but to skip reading the response — because we don’t know when the full response is received.
The correct fix is to fix the server so that it responds in a non-ambiguous way that avoids this problem. The entire reason for the Content-Length header, or the chunked transfer encoding, is for the client to know when the full response has been received. A server that does not provide this information will cause problems with clients hanging or not receiving the full response because there is literally no way to know when the full response has been received. (Fix the damn server!)
But as usual, Chilkat will provide a way to hopefully get around brain-dead servers that refuse to be implemented properly. Starting in v220.127.116.11, you can add the keyword “ReadResponseUntilConnectionClosed” in the rest.UncommonOptions. This will cause Chilkat to read the HTTP response until the server closes the connection (even though the server did not indicate it will be closing the connection via the “Connection: close” header, hopefully the server still intends to close the connection after sending the response, and if so, then it will be possible to read the response.