Draft spec update: https://github.com/w3c/navigation-timing/pull/5 - thoughts, comments?
ig On Wed, Oct 15, 2014 at 7:35 PM, Ilya Grigorik <[email protected]> wrote: > 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 <[email protected]> > wrote: > >> On Wed, Oct 15, 2014 at 12:46 PM, <[email protected]> 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 >> >> >> >
