-3

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?

Maarten Bruins
  • 189
  • 12
  • If you have a Mozilla bug report for this, would you add that into the question? That will allow readers to explore any feedback you get elsewhere (both now and in the future). – halfer Nov 23 '17 at 14:14
  • @halfer Thanks! I'll do that. First i will post the other parts of the bug report, so i can do it at once. But i can only post something every 90 minutes or something (at this moment), so probably it's going to take 2 days, because i have more 8 posts or something in the pipeline. First for me that was a reason to put everything in 1 question, but that was not the way to do it ;), so now it will just take some longer. Not really handy that delay, but the only thing i can do, is accept it. I'll add some things in the bug report after my posts here, so that's why i want to do it at the end. – Maarten Bruins Nov 23 '17 at 14:23
  • @halfer Maybe it's too much off-topic here, so if you want i'll remove this comment. But it would be nice if for example you (or other trusted members) could reduce the delay between posts for me. If the community thinks i'm abusing it, they can always change it back. Now the good ones suffer from the bad. I don't have spam intentions or whatever. – Maarten Bruins Nov 23 '17 at 14:29
  • 1
    Ooh, no, don't do that. I can't modify that delay, and I doubt moderators can either - it is probably set based on your current reputation. I don't think anyone should be churning out nearly-identical questions at such a rate, in any event. In your case, since you're new, you might make an error that causes the whole set to (on average) received badly, and a random set of downvotes across ~8 more posts could cause your account to have a question ban applied. – halfer Nov 23 '17 at 15:10
  • @halfer But I'm gonna split some questions (there was one more on hold), because I put too much different things in one question. So it's too broad. If you watch it in detail, then all the new questions are completely different in essence. So don't worry about it. You will see what i mean after i posted all the questions. I will let you know when i'm done with all of them. I think you will agree with me, but anyway otherwise you could always let me know. – Maarten Bruins Nov 23 '17 at 15:49
  • @halfer Really unbelievable again. What's now wrong about this question? I really think people are abusing their downvotes. I really have no idea what i did wrong or how i could make the question better? – Maarten Bruins Nov 23 '17 at 18:26
  • 2
    I don't think there is much advice that I can offer. As long as someone is not focussing downvotes on you deliberately, the vote is not abusive, and someone is perfectly entitled to make it. It may be that someone saw you asked for advice, I gave you some advice, and you responded by saying you won't take it. You've already asked six questions in two days, which I think is excessive, some of which are heavily downvoted, and you've promised to ask another six or so. My guess is that you are teetering on the edge of a question ban by now (though the algorithm for that is not public). – halfer Nov 23 '17 at 18:40
  • 2
    My last contribution to this thread: the more questions you ask about this, the more I am convinced that my advice on one of your prior questions was correct. Download the source code to Firefox, make sure you can compile it, and then add some debug statements into the source code, so you can understand how the HTTP response code and Length meta-data values are derived in various situations. Good luck! – halfer Nov 23 '17 at 18:42
  • @halfer Thanks, but to be honest I don't understand exactly what you mean. This question is about Mozilla Firefox forgot about the status code in the raw response headers. Please explain me what your suggestion would contribute to this specific question. They just forgot about the status code, so there is not that much to understand about it. So your comment is not really useful to me concerning this specific question. And on purpose I splitted the questions, so we can be really specific on some question. And if you know the answer to this specific questionss, you can answer it. – Maarten Bruins Nov 23 '17 at 18:52
  • FF didn't forgot any headers. You are just misinterpreting facts without bothering to inform yourself. Again. The line you say is missing from the headers FF shows, is actually the status line; not part of the response headers. [Those two are different things](https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html). – yivi Nov 24 '17 at 07:44
  • @yivi Misinterpreting? I'm asking a question: "how i have to see it" I'm not drawing any conclusions. That's your conclusion. But if the status line is not part of the response headers, then actually the size of the response headers is wrong, because they are counting that line (both Chrome and Firefox). How do you explain that? Then anyway they are not consistent at all. – Maarten Bruins Nov 24 '17 at 07:50
  • 3
    You are asking if what you see is a FF bug. SO is no the right place for that. Making it even worse, the supposed _bug_ it’s something that at best could be said to be a matter of opinion. You say FF is in the wrong. Go and tell Mozilla; SO is not the place to have a discussion about it. – yivi Nov 24 '17 at 08:12
  • @yivi I totally disagree with you. It's just about definitions and what is officially part of the "response headers". And one more time: I'm not saying here: IT IS A BUG. I'm saying: "Is this a bug or how I have to see it?" But anyway, Stack Overflow is about programming questions. I did not realize that at the moment i started this question. So i agree with you that this is not the place for it, but because of a different reason. I'll leave Stack Overflow anyway. It's the wrong platform for most of my "questions" anyway. Thanks for your help. – Maarten Bruins Nov 24 '17 at 08:46
  • Actually I already left Stack Overflow, because it's not the platform for me, but people here asked for the bug report. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1419401 They're gonna change it, so fortunately at least they understood me and that's the most important for me. – Maarten Bruins Nov 29 '17 at 11:10

1 Answers1

-1

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.

Community
  • 1
  • 1
Maarten Bruins
  • 189
  • 12