Open Bug 1419404 Opened 7 years ago Updated 2 years ago

Value in "Size" column doesn't conform with expected value

Categories

(DevTools :: Netmonitor, defect, P3)

57 Branch
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: bruinsmaarten, Unassigned)

References

(Blocks 2 open bugs)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce: See: https://stackoverflow.com/questions/47412949/where-is-the-logic-behind-mozilla-network-monitor-in-firefox-developer-tools-in Summery see bold part in that post / question: "3. Or the definition of "Size" is wrong or it's not working properly. See "Firefox Developer Tools" > Network." in that post. Actual results: The definition of "Size" does not match the results of "Size" in "Firefox Developer Tools" > "Network". Expected results: The results must match the definition.
Component: Untriaged → Developer Tools: Netmonitor
As in bug 1419402, I tried to clarify the summary. It might be that the description on MDN[1] is just incomplete/incorrect. It currently says: "Size: the size of the transferred resource." Sebastian [1] https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor#Network_request_list
Summary: OR the definition of "Size" is wrong OR it's not working properly. ("Firefox Developer Tools" > Network) → Value in "Size" column doesn't conform with expected value
"Firefox is talking about the size of the TRANSFERRED resource, but in case of compression the size of the transferred resource is less." So with that definition, the value of "Size" must be dependend of whether there is gzip compression or not. So actually "size" must have the same value as "Content-Length". Because in case of gzip compression there are less bytes transferred. See for example in the link i posted: "CASE 2A: GZIP COMPRESSION: YES, STATUS CODE: 200 OK" In that case "Size = 143 B", while Content-Length is 127, so the compressed version of the entity-body is 127 bytes. So 127 bytes are transferred and not 143 bytes. So in my opinion the correct value of "size" had to be 127 bytes and not 143 bytes.
They banned me on Stack Overflow ;). I posted a link to Stack Overflow to report the bug (which was not that clear anyway), so maybe they will remove that link, so i'll post the bug one more time (a bit more clear) here. See: https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor#Network_request_columns They are giving me this definition: > <b>Size:</b> the size of the transferred resource. My version of Firefox is: 57.0 (64-bit) - Firefox is up to date. I did some tests and the results in Firefox (my version) are: 1. In case of gzip compression, the value of "Size" is the amount of bytes, <b>WITHOUT</b> taking into account the compression. 2. In case of "200 OK (cached)" or "304 Not Modified", the value of "Size" is the amount of bytes of the entity body. In case 1, I would expect that the compression would have influence on the value of "Size", because there are less bytes transferred (because of the compression). So they have to take the bytes of the compressed entity-body in my opinion and not the bytes of the uncompressed entity-body. In case 2, I would not count the bytes of the entity-body at all, because they are not transferred at all. Because the entity-body is coming from cache. So anyway, or the results are wrong, or the definition is wrong. The definition would match the results, if the definition would be: > <b>Size:</b> Just the size of the resource. Not the size of the transferred resource, because with or without caching, "Size" will stay the same. There is also no difference in "Size", with or without compression. If the definition is just wrong, then actually it's not a real bug, but then please adjust the definition, because now it's confusing.
Product: Firefox → DevTools
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.