- From: ??? <willchan@chromium.org>
- Date: Thu, 16 Oct 2014 10:05:18 -0700
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: Tobin Titus <tobint@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, public-web-perf <public-web-perf@w3.org>, Mark Nottingham <mnot@mnot.net>, Tony Gentilcore <tonyg@chromium.org>
+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? * How is this property populated when serving from cache? * Are we restricted to ALPN Protocol IDs? What about experimental protocols like QUIC? * Are we potentially revealing more information than we should be about the network configuration? For example, when a proxy is configured. * How does this interact with Service Worker resource fabrication? When the SW synthesizes a resource, what value do we report here? But in general, yes, I am very supportive of trying to expose this information for RUM purposes. Let's do it somehow :) 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 >> >
Received on Thursday, 16 October 2014 17:05:45 UTC