Re: negotiated protocol in Navigation and Resource Timing

On Thu, Oct 16, 2014 at 10:05 AM, William Chan (陈智昌) <willchan@chromium.org>
wrote:

> +tonyg to get his opinion
>
> Some questions:
> * NT/RT is generally used for post-mortem analysis. I believe tonyg@
> has been opposed to providing guarantees on how quickly it gets
> populated. Does that limit the usefulness of the protocol here?
> Suppose you wanted to dynamically change behavior based on protocol
> used to deliver resources (e.g. a prioritized multiplexing protocol is
> available, so you can issue resource requests immediately rather than
> implementing a scheduler in JS). Is this information perhaps better
> provided in the fetch Response object?
>

It may make sense to provide protocol info on the Response object, but I
don't think that's a strong argument against exposing the protocol in
RT/NT. There are some rough plans to allow retrieving Response object from
an element (e.g. <img>), but that's an involved affair that requires
iterating over the DOM, and it still doesn't cover the case of the parent
page (covered by NT) -- i.e. I can't get the Response object for the
navigation.

As such, at a minimum, I think we need to provide protocol info in NT, and
for consistency and convenience I think we should also surface it in RT.
That said, curious what others think...

Re, changing fetch behavior: I think that's a valid use case. I may indeed
want to change how I fetch some of my assets based on the protocol of the
parent page or a particular origin. We should populate the protocol field
as soon as we know it.


> * How is this property populated when serving from cache?
>

Hmm, good question. Empty value?


> * Are we restricted to ALPN Protocol IDs? What about experimental
> protocols like QUIC?
>

I'll defer to Mark on this one :)


> * Are we potentially revealing more information than we should be
> about the network configuration? For example, when a proxy is
> configured.
>

If you have a tunnel connection, we don't expose any extra information. If
you don't tunnel, then we have no idea what the proxy may be using to talk
to the server, hence we report the protocol to the proxy (that's all we
know).

So, yes it would be possible to detect *some* instances where user is
routed through a proxy. I think that's worth calling out in the
privacy/security sections, but I don't think that should block us from
exposing the protocol.


> * How does this interact with Service Worker resource fabrication?
> When the SW synthesizes a resource, what value do we report here?
>

I think this falls into same bucket as cached response. Empty value?

ig


> On Wed, Oct 15, 2014 at 7:16 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> > After a few iterations (thanks Mark!), we've arrived at:
> >
> > ------- (discussion @ https://github.com/w3c/navigation-timing/issues/2)
> > ------
> >
> > readonly attribute DOMString protocol;
> >
> > This attribute must return protocol used to fetch the resource, as
> > identified by the ALPN Protocol ID (see
> > https://tools.ietf.org/html/rfc7301). When a proxy is configured, if a
> > tunnel connection is established then this attribute must return the ALPN
> > Protocol ID of the tunneled protocol, otherwise it must return the ALPN
> > Protocol ID of the first hop to the proxy.
> >
> > In order to have precisely one way to represent any ALPN protocol ID, the
> > following additional constraints apply: octets in the ALPN protocol must
> not
> > be percent-encoded if they are valid token characters except "%", and
> when
> > using percent-encoding, uppercase hex digits must be used.
> >
> > Note that this attribute is intended to identify the protocol in use for
> the
> > fetch regardless of how it was actually negotiated; that is, even if
> ALPN is
> > not used to negotiate the protocol, this attribute still uses the ALPN
> > Protocol ID's to indicate the protocol in use.
> >
> > ----------
> >
> > Above would apply to Navigation Timing and Resource Timing - aka, you can
> > get the protocol for each resource fetch.
> >
> > Tobin: could you run this by the IE networking team for feedback?
> > Patrick: any feedback from Mozilla side?
> >
> > ig
> >
> > On Tue, Oct 14, 2014 at 7:47 PM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> >>
> >>
> >> On Tue, Oct 14, 2014 at 3:26 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >>>
> >>> Gave my feedback on the issue. I think you misunderstand -- ALPN isn't
> >>> required to be used to use its protocol identifiers as a name space.
> That's
> >>> what a lot of protocols are currently doing (e.g., RTC, TURN).
> >>
> >>
> >> Doh, you're right, misread your original proposal. Thanks for the
> >> clarification!
> >>
> >> How about this:
> >> https://github.com/w3c/navigation-timing/issues/2#issuecomment-59150636
> -
> >> getting closer?
> >>
> >> ig
> >>
> >
>