Re: Support for page/resource size

On Thu, Jul 10, 2014 at 5:54 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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?


Approaching this from the point of view of the developer who will be using
this API: I expect this number to match whatever Content-Length reports in
my developer tools. First and foremost it should provide me with an
accurate measure of bytes transferred between client and server (i.e.
compressed size if compression was applied), and if possible, the decoded
size as well. The size of HTTP headers and other overhead is a separate
story, and I'm not sure we need to get into that.


>  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?


Once again, it should match what I see in developer tools: 304, and 0 for
size (Chrome DevTools shows "from cache").

ig