Re: negotiated protocol in Navigation and Resource Timing

On Sat, Oct 18, 2014 at 2:17 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Oct 17, 2014 at 5:49 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> > We need protocol info in Navigation Timing because there is no way to get
> > the Response object for the navigation. That said, I would also like to
> see
> > it on Resource Timing: developer convenience, consistent API interface.
>
> What exactly is "protocol info"?
>

This discussion probably belongs in a separate thread, but briefly:
http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0059.html

Question is whether the Response object (
https://fetch.spec.whatwg.org/#responses) could/should contain an
equivalent .protocol attribute as proposed above, alongside status, status
message, etc.


> > Also, right now we're working on the assumption that Fetch's Response
> object
> > could/should expose the protocol.
> >
> > Anne: any thoughts on the latter?
>
> It exposes the protocol insofar that it exposes the scheme  through
> the response's url.
>

Right, we're after the transport layer ALPN ID - e.g. https -> {http/1.1,
spdy/3, http/2, ...}.


> (It wasn't clear to me we wanted to expose the response of an <img> as
> well by the way. I thought we just wanted to control the request for
> it. It seems doable, although e.g. <img> can represent many requests
> and many responses so we likely cannot have a generic solution.)
>

Ah, I always assumed we'd expose both, but you're right, the functionality
we've discussed previously is all on Request... Hmm, will have to noodle on
this one some more. In the meantime, this is a good argument for why
"protocol" + {transfer, decoded}Sizes should, in fact, be exposed via NT/RT.

ig