Re: Support for page/resource size

On 7/10/14, 5:03 PM, Philippe Le Hegaret wrote:
> On Wed, 2014-07-09 at 18:13 -0400, Anthony van der Hoorn wrote:
>> Additionally (and I say this hoping it's not pushing my luck), I would like
>> to know the "over-the-wire" size vs the "actual" size (chrome dev tools
>> calls this "content" vs "size"). That way we can start flagging requests
>> that aren't compressed, see bandwidth cost of payload, etc.
>
> We'd need feedback from implementers here to know if it's possible.

It depends on how "over the wire" size is defined.  Are we talking about 
the size of the HTTP "payload body" (in RFC 7231 terms; "message body" 
in RFC 2616 terms)?  Or are we talking the size of the actual HTTP 
messages?  Or are we talking about actual bytes on the wire, whatever 
wire means?

Specifically, given some data that is sent with Content-Encoding:gzip 
and Transfer-Encoding:chunked over an SSL connection, are we measuring 
the size of the HTTP "message body" (which in this case is gzipped, 
note), or the "payload body" (which has the extra bytes for the chunked 
encoding) or the actual HTTP messages (which include headers in addition 
to the data) or the size of the TCP packets (which include SSL overhead 
bits and the HTTP messages in encrypted form, plus the TCP handshake 
itself) or something else?

Basically, what is the goal of measuring this number?

> As far as I can tell, we discussed it back in 2011 [1], but didn't
> follow on it either. At the time, the conclusion was that it was
> possible to do it for same-origin resources at least. However, again,
> the response may come from the cache.

Caches have to know the status code of the cached response, generally, 
so they can provide it to consumers.

More interesting is what the status code should be reported as if the 
browser did a conditional request and got back a 304.  Is the status 
code 304 or whatever the status code for the cached response is?

-Boris

Received on Friday, 11 July 2014 00:55:02 UTC