Content-Length:header in the response and with that specify the exact number of bytes in the response body.
--ignore-content-length. Doing so may have some other negative side-effects but should at least let you get the data.
--write-outoption to extract the response code. See the --write-out section.
--fail-with-body. Then curl will exit with error code 22 for such occurrances.
--write-outto extract that code as well.
Transfer-Encoding: chunkedheader that tells curl there's chunked data coming and then in the response body, the data comes in a series of "chunks". Every individual chunk starts with the size of that particular chunk (in hexadecimal), then a newline and then the contents of the chunk. This is repeated over and over until the end of the response, which is signalled with a zero sized chunk. The point of this response encoding is for the client to be able to figure out when the response has ended even though the server did not know the full size before it started to send it. This is usually the case when the response is dynamic and generated at the point when the request comes.
Content-Encoding: gzipin the response as a hint to the client. Compressed responses make a lot of sense when either static resources are sent (that were compressed previously) or even in run-time when there's more CPU power available than bandwidth. Sending a much smaller amount of data is often preferred.
Content-Encodingas described in the section above. But HTTP was originally intended and specified to allow transparent compression as a transfer encoding, and curl supports this feature.