- From: 陈智昌 <willchan@chromium.org>
- Date: Fri, 17 Oct 2014 09:10:19 -0700
- To: Ilya Grigorik <igrigorik@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, 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>
I'm more or less fine with the arguments you've presented. I think I've pointed out all the issues that caught my eye, and I still think we should provide this information to the web platform in some form. I leave the rest of the details to y'all :) You should really confirm with Tony about the time availability of this info in NT/RT. On Fri, Oct 17, 2014 at 8:49 AM, Ilya Grigorik <igrigorik@google.com> wrote: > 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 16:10:47 UTC