Re: negotiated protocol in Navigation and Resource Timing

On Thu, Oct 30, 2014 at 8:28 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Oct 23, 2014 at 6:17 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> > So, if the response comes from cache, is a local resource, etc, then we
> skip
> > over 17 and networkProtocol is null... which, I think, makes sense? Same
> > logic would apply for Resource Timing as well.
>
> You did not mark the attribute nullable. But I wouldn't return null
> from something that typically returns a string if I could avoid it.
> Returning the empty string seems better.


Good catch, thanks. I've added a step to initialize it to the empty string
at step 5:
- preview: https://rawgit.com/w3c/navigation-timing/protocol/index.html
-
https://github.com/w3c/navigation-timing/commit/44e7f8f57b03efe4831b90b07f7a3948e470b61a

Also, based on feedback from TPAC, updated the name to "nextHopProtocol" --
any objections from the list? Going once, twice... :)

Also, if there's a fixed list
> of protocol IDs the browser support, an enum would be more
> appropriate, updated over time.
>

There isn't. E.g. QUIC is revving versions on an (almost) monthly basis.
The fact that we're relying on an ALPN ID should be sufficient.


> > http://w3c.github.io/navigation-timing/#processing-model
>
> This seems to tack a lot of information on top of
> https://fetch.spec.whatwg.org/ without actually defining it at the
> core. It would be better if this information was defined in Fetch and
> these API drafts just exposed it.
>
> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=23878 for some
> exploration how to better approach defining the various things
> resource and navigating timing attempt to define.


Interesting! Thanks for the context. Definitely something to consider, but
I don't think it blocks what we're discussing here.

ig