Re: transfer and resource size in Navigation + Resource Timing

Based on the feedback from the conference call, current proposal is as
follows:

------(discussion @ https://github.com/w3c/navigation-timing/issues/3)------

Transfer size (transferSize): this attribute must return the size, in
octets received by the client, consumed by the response header fields and
the response message body [1]. This SHOULD include HTTP overhead (such as
HTTP/1.1 chunked encoding and whitespace around header fields, including
newlines, and HTTP/2 frame overhead, along with other server-to-client
frames on the same stream), but SHOULD NOT include lower-layer protocol
overhead (such as TLS or TCP).

Decoded size (decodedSize): this attribute must return the size, in octets,
of the message body used, after removing any applied content-codings [2].

------

[1] http://httpwg.github.io/specs/rfc7230.html#message.body
[2] http://httpwg.github.io/specs/rfc7231.html#data.encoding

For examples of 200/304/cache fetches and reported values, see bottom of:
https://github.com/w3c/navigation-timing/issues/3#issue-45803731

Anne+Boris raised some good questions on the GitHub thread, and we're still
working through those.

*Tobin: *could you also run this one by the IE networking team?

ig

On Wed, Oct 15, 2014 at 7:08 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> On Wed, Oct 15, 2014 at 12:46 PM, <bizzbyster@gmail.com> wrote:
>>
>>
>>    - I don't believe we need to expose HTTP response codes; they're
>>    unnecessary.
>>
>> Is there some reason not to expose the HTTP response codes?
>>
>
> The issue we're discussing here is how and whether to expose transfer and
> decoded sizes, HTTP response codes are orthogonal and should be moved into
> a separate discussion. I'd like to keep this thread focused so we can make
> progress on {transfer, decode}Sizes.
>
> ig
>
>
>