But I can not understand why there is no response body, only headings.
Because you are likely processing the NetData before the response body has actually been received.
You can't process the NetData as-is, let alone as strings. It may be incomplete data on any given event.
TIdMappedPortTCP is just a passthrough of
arbitrary raw bytes in both directions. It knows NOTHING about HTTP (or any other protocol that exists on top on TCP). It simply runs a loop for the lifetime of the inbound and outbound connections, where each loop iteration checks if the 2 connections have any pending bytes waiting to be forwarded to the other connection, and if so then reads the bytes, fires the OnExecute (inbound connection) and/or OnOutboundData (outbound connection) events, in that order, and then forwards the bytes. The events allow you to modify the bytes, but they are still just
arbitrary bytes at any given moment.
If you need to process the bytes, you have to parse them yourself. And since there is no 1:1 relationship between reads and sends in TCP, you have to buffer the NetData yourself and parse your buffer instead of the NetData itself. That also means implementing a state machine to know what data you are parsing on any given event, as your buffer may contain a mix of partial messages and complete messages, so it may take multiple events to process any given message, or you may have to process multiple messages in a single event.
So, in this case, since you are trying to extract an HTTP server's response body, then in the OnOutboundData event, append the NetData as-is to the end of your own buffer. EVERY TIME the OnOutBoundData event is fired, after copying the NetData into your buffer, scan your buffer for the '$0D $0A $0D $0A' byte sequence that separates HTTP headers from HTTP body, and if found then extract the HTTP headers from the buffer, take note of how the HTTP body (if present) is formatted and terminated (see
RFC 2616 Section 4.4 for the rules), and then read the body data as needed, in a loop, updating your state machine on each iteration, until the buffer no longer holds a complete message. It may potentially take multiple OnOutboundData events for you to reach the end of the headers, and/or the end of the body. Then, and only then, can you process the headers and body as needed, and then start all over for the next HTTP response.
You had to do something to this in the old Indy version, too. If you weren't, then you weren't using TIdMappedPortTCP correctly to begin with.
Things get a bit more complicated when you have to deal with things like SSL/TLS, HTTP pipelining, compression, etc.
If you are trying to create an HTTP proxy to capture traffic back and forth, you really should use TIdHTTPProxyServer instead of TIdMappedPortTCP. TIdHTTPProxyServer has OnHTTPBeforeCommand, OnHTTPResponse, and OnHTTPDocument events. Let TIdHTTPProxyServer handle the HTTP protocol for you, and provide processed data to you.