Why is content-length required in case of HTTP persistent connections

Question

My understanding of how data transfer happens in tcp/http is this:

The application layer on the server side passes some data to the tcp layer to be sent to the client. The tcp layer breaks the application data into segments and sends it further. The tcp layer on the other end will ensure that it receives and arranges all the segments in order before passing them to its application layer.

Now, in the case of non-persistent connections, the server can simply close the connection when it is done sending data. What does this mean? Does it mean the server will send a FIN segment at the end? So, the client's tcp layer will basically wait for all the segments upto the FIN segment, pass this data to the upper layers and proceed with connection termination.

In the case of persistent connections, as the connection is not closed by the server, it is said that the client cannot know when it has to finish reading the response and do the next request. And so the content-length header and chunked transfer are used.

My question is "why can't we just send a segment similar to FIN (say DONE) to indicate that the server has transmitted all the response". The client on seeing DONE can start with the next request. What was the need to include a content-length header which comes with the issue of knowing the content length in advance?

I am sure I have misunderstood or missed something here. Please correct me where I am wrong above.

Thanks for reading upto here :)

Answer 1

Imagine what would happen if your HTTP-payload data contained DONE in its middle.

TCP FIN packets on the other hand mark the FIN within the TCP header's flags and thus, there is no danger of errorneously mistaking some data packet as a FIN packet.

Answer 2

Because DONE might occur in the body of the response, as there is no escape mechanism specified in the protocol.