If the response has a body / can have body (i.e status code is not 204 or 304), should it always have either content-length or Transfer-Encoding in the response header. In the spec it is not very clear.
In my scenario I have a body without content-length or transfer encoding header, so the curl is keep on waiting no chunk, no close, no size. Assume close to signal end while other clients (like postman) are getting the content without hanging.
Transfer-Encoding is a HTTP/1.1 addition. So, that version of the protocol seems relevant here.
It states about Content-Length:
it SHOULD be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules in section 4.4.
This clearly indicates that it is not required to be sent.
With Transfer-Encoding the standard states:
The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient.
This allows for leaving out the header field if no transfer encoding is being applied.
From this follows: both headers may validly be missing from a response.
In your case curl is telling what it does: It is waiting for the remote side to close the connection for knowing the data has been fully received.
You should provide your curl flags and the relevant communications from -v to allow more insight in why other tools seem to get a better idea on why there is no more data before EOF has been encountered.
RFC 7230 has a very detailed description of this (see Section 3.3.3). In particular, the last point:
- Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection.
