- From: Ilya Grigorik <igrigorik@google.com>
- Date: Fri, 17 Oct 2014 08:49:00 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>, Anne van Kesteren <annevk@annevk.nl>
- Cc: Peter Lepeska <bizzbyster@gmail.com>, 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>
- Message-ID: <CADXXVKqwoCu2ormy53A7u7DEB=9Vh7NQgQ+vTD8ZwinPiJg3MQ@mail.gmail.com>
On Thu, Oct 16, 2014 at 3:36 PM, William Chan (陈智昌) <willchan@chromium.org> wrote: > > > 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> > > 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. > > Mostly I'd prefer not to duplicate data in multiple places. > 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. 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? > >> * How is this property populated when serving from cache? > > Hmm, good question. Empty value? > > Btw, we already leak whether or not a response was cached in other > ways, right? This should be mentioned in the privacy considerations. > Not sure "leak" is the right word. It has always been possible to test for this: time the request, modify the URL to cache-bust and time that, compare the two and voila.. a pretty solid way to answer the "in cache" question. That said, yes, an empty protocol value for a cache fetch makes this explicit - something we should document in privacy+security sections. > >> * Are we restricted to ALPN Protocol IDs? What about experimental > >> protocols like QUIC? > > > > I'll defer to Mark on this one :) > > Well, I'm going to insist on being able to experiment. And ALPN is an > interesting choice since QUIC obviously doesn't get deployed using > ALPN :P > https://github.com/w3c/navigation-timing/issues/2#issuecomment-59127537 ALPN ID is simply the namespace / shared registry of names, and QUIC can register own values as it revs each version. There is no requirement that you actually use ALPN. > > I think this falls into same bucket as cached response. Empty value? > > I forget how SW interacts with NT/RT, but I sorta view this as a > reason to tag the protocol in the Response object. The SW may be > initiating fetches from the worker context rather than a document > context, so there's no document RT/NT to report the resource fetch. > I don't think it's "forget"... it's undefined, and something we should discuss in a separate thread. ig
Received on Friday, 17 October 2014 15:50:08 UTC