EDIT: Later on it seemed that some browsers are confusing the term "response headers" with "response message (without response body)". So that's where this question was coming wrong. The browsers were just incorrect. Meanwhile I gave answer to my own question.
In Firefox you can check the "raw headers" via "Firefox Developer Tools" > "Network".
Example of the raw response headers:
Date: Thu, 23 Nov 2017 12:43:21 GMT
Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16
Connection: Keep-Alive
Keep-Alive: timeout=1, max=100
Cache-Control: max-age=9, public
Vary: User-Agent
But I miss (for example): "HTTP/1.1 304 Not Modified". Firefox shows somewhere else "304 Not Modified", but not RAW.
So they let me think I have the response headers in raw form, but actually it's only a part of the response headers, excluding the status code. This can be really confusing for people. In my opinion it would make much more sense to add the "status code" too at that place. Now it's not really logical.
Is this a bug or how I have to see it?
Meanwhile I can answer my own question.
At this moment, some browsers are usings terms wrong. They are confusing "reponse headers" and "response message (without message body)". So that's why I was confused when asking the question and that was what the question was about.
See: https://www.rfc-editor.org/rfc/rfc7230#page-8 (2.1. Client/Server Messaging)
A server responds to a client's request by sending one or more HTTP response messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (Section 3.1.2), possibly followed by header fields containing server information, resource metadata, and representation metadata (Section 3.2), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, Section 3.3).
So with other words.
RESPONSE MESSAGE:
Status line (ending with CRLF, so 2 extra Bytes)
Header field 1, in case of (ending with CRLF, so 2 extra Bytes)
Header field 2, in case of (ending with CRLF, so 2 extra Bytes)
Header field 3, et cetera (ending with CRLF, so 2 extra Bytes)
Empty line to indicate the end of the header section (CRLF, so 2 extra Bytes)
Message body / Response body, if any
RESPONSE HEADERS / RESPONSE HEADER FIELDS:
Header field 1 in case of (ending with CRLF, so 2 extra Bytes)
Header field 2 in case of (ending with CRLF, so 2 extra Bytes)
Header field 3 et cetera (ending with CRLF, so 2 extra Bytes)
So officially the status-line is not part of the "reponse headers", but only part of the "response message".
Firefox is for example showing the size of the "reponse headers" in: "Firefox Developer Tools" > "Network" > click on row > Headers tab.
This size also includes the size of i.a. the status-line. The size of the raw response headers must correspond this size, but that's not the case at this moment. So or they need to change the size, or they must extra include the "status-line" + "empty line" in the (raw) response headers and they must give it another name (for example: response message - message body).
Chrome is also doing this wrong. For example see: https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#requests
They are saying there:
Size. The combined size of the response headers plus the response body, as delivered by the server.
But they actually mean something different (also according the value of size in practise). They actually mean this:
Size. The combined size of the response message, without the message body (instead of response headers) plus the response body, as delivered by the server.
So actually with other words:
Size. The combined size of the response message, as delivered by the server.
So that's where my origin question was coming from. Apparently it's a difficult subject for browsers at this moment, because I tested it in 2 browsers and both are making mistakes with it.
So because of that, it's not weird if people would think the status-line is part of the response headers.