Re: negotiated protocol in Navigation and Resource Timing

"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…”

Needs to be in RT to be able to understand performance characteristics of objects fetched from non-same-domain.

Peter

On Oct 16, 2014, at 3:13 PM, Ilya Grigorik <igrigorik@google.com> wrote:

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