PerformanceNavigationTiming decodedBodySize larger than encodedBodySize if resource is not encoded

• Component: Page Loading
• Status: REOPENED ---

[Gernot Raudner]

On a resource that has no encoding headers specified (e.g. no gzip, example website: https://gernotraudner.at), Safari 17.4.1 reports the `decodedBodySize` smaller than the `encodedBodySize`. In this specific example, the `decodedBodySize` is 294, while the `encodedBodySize` is 303. I can guarantee the server does no encoding, and it doesn't respond with any encoding headers. This seems to work fine with encoded resources though (`encodedBodySize` being smaller than `decodedBodySize`, as expected). So, to reproduce, simply

1. Open the network tab in devtools
2. Go to https://gernotraudner.at
3. enter `const navtimings = performance.getEntriesByType("navigation")[0]; console.log("encoded: ", navtimings.encodedBodySize, ", decoded: ", navtimings.decodedBodySize);` in the console
4. check the network tab and select the resource, check the sizes

In #3 you can see that the `encodedBodySize` is larger than the `decodedBodySize`, which cannot be the case.
Additionally, in #4 you can see that the "Bytes Received" of the body are 303B, while the resource size is 0.29KB. The tab also shows that compression is 0.97x (making it actually larger?).

I'm not 100% certain, but I think this used to work in Safari 16.

[Alex Christensen]

That 9 byte difference seems to be from the HTTP/2 framing overhead: https://datatracker.ietf.org/doc/html/rfc9113#section-4.1
This is arguably correct, but now you know what that's from.

[Gernot Raudner]

Maybe my example was bad, or this is a separate issue, not sure... I also have a webserver that doesn't support HTTP/2, and the difference is, interestingly enough, 18 bytes (35910 compressed versus 35892 decompressed).

It doesn't really solve my issue either, because I compare the data I generate on the server with the data I receive on the client, and even though the body matches, as well as the encodedBodySize (of course, since it's not encoded), but the decodedBodySize is invalid. I don't really see how this is arguably correct in the context of the Performance API. It might be correct in the context of HTTP frames, but this shouldn't be linked to the Performance API, should it?

[Alex Christensen]

Could you send me a link to that server?  Feel free to email it to me by clicking my name if you don't want to post it on this public bugzilla.

[Gernot Raudner]

sorry for not replying for so long. i built a little reproducer: https://github.com/DerGernTod/safari-decoded-body-size/tree/main

the server is serving http/1.1 so the http/2 framing overhead you mentioned doesn't apply. also, wouldn't the "bodySize" only refer to the body, and not to the framing?