Re: [Resource Timing] Spec updated per Action 3 and Action 4

On Wed, 30 Mar 2011 23:30:44 +0200, Jatinder Mann <jmann@microsoft.com>  
wrote:

Thanks for detailed feedback, glad to see my input was of some use.

>> Should we include a RESOURCE_FAVICON?
>
> If the favicon is initiated by a LINK, then it should have  
> INITIATOR_LINK. If it's not specified in the page, and the browser  
> downloads it on its own, we will not include it.
>
>> What about OCSP, CRL, intermediate certificates, reputation checking,  
>> etc?
>
> Since no objects are initiating the requests for these resources, they  
> should not be included. We should instead capture the timing information  
> with a secureConnectionStart timing data, like we do in the Navigation  
> Timing spec.

OCSP, CRL and reputation checking might all happen after the handshake,  
and on an insecure channel to a third party host. Yet they may in some  
circumstances prevent onload on (or even display of) the page. Favicons  
too might delay page onload, as well as security policies (e.g. Flash's  
crossdomain.xml). If we do not include these 'background requests', then a  
vital part of why the page took so long to load might be lost.

I am not certain if this is important or not, but it should at least be  
worth noting, possibly also in the spec, that it might not capture  
everything that is required for a page to load.

Note too that giving out detailed information (for instance url) about  
e.g. reputation checking might be a privacy issue.

>> What about the param tag, and longdesc, usemap, classid, codebase, data
>> and other attributes which use URLs?
>
> One of the goals of having the initiator attribute is to help web  
> developers group their resources by common initiator type. For less  
> commonly used initiator types, we should rely on INITIATOR_OTHER. The  
> data is not lost, as the web developer can always look at the URL and ID  
> attributes.

I fear the INITIATOR_OBJECT might be confusing. The object tag might or  
might not have any direct resource loaded, the url is sometimes in a param  
tag instead. Though conceptually this is normally simple, we might have to  
specify what we're thinking of in the spec - the main resource file for  
the object tag, regardless of which attribute or param tag it is loaded  
through.

>> How do we treat resources requested through the browser from a plugin,
>> are they included?
>
> As mentioned above, if the third party plugin modifies the page itself,  
> it should follow the existing initiator rules.

And if Flash requests an xml file for it's own internal use, but through  
browser APIs? Thus possibly delaying other requests from the browser, and  
slowing down the page load.

>> Or when the .src of an
>> image is dynamically changed, do we keep the timing data for the old  
>> image
>> (it might have been an important part of the load process), or do we  
>> discard
>> the old data and overwrite with the new (even if the new data is no  
>> data)?
>
> If the second fetch goes to the networking layer, it will be treated as  
> a new resource in the PerformanceResourceTiming interface. There is  
> never a scenario where we will be overwriting existing data. We can add  
> specific examples for these in Section 4.2 to make it clear.

I think my question was also answered below, 'id' isn't unique, there may  
be several timings for a given id.

>> Regarding cross domain regulation, let us not invent the wheel again  
>> with yet
>> another HTTP header. Webmasters are drowning in headers already, and
>> setting up a server requires understanding and keeping track of all of  
>> them.
>> Let us piggyback on some existing system instead, it will be easier for
>> webmasters, and we get additional benefits such as support for a policy  
>> file.
>> E.g. CSP on  
>> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-
>> specification.dev.html
>> which is being heavily discussed on public-web-security@w3.org these  
>> days.
>
> We looked at other CORS spec and the other HTTP response headers, but  
> did not wish to overload existing headers as they may enable additional  
> behavior that was not intended by someone just trying to gather Resource  
> Timing information.
>
> What state is the CSP spec in? It wasn't very clear? We are worried  
> about taking a dependency on another spec that is not stable. We would  
> rather define the behavior in our own spec and not take a dependency.

My very personal and unoffical feeling about the CSP spec is that it is in  
the state of too many cooks, and might be a long way from completion. I  
agree fully with not wanting to overload other headers, but we also don't  
want to introduce new obscure security settings/methods for webmasters to  
keep track of, we should reuse an existing framework. For CSP, we would  
likely have to introduce our own attribute, but it could be kept in the  
framework of CSP.

Unfortunately, such headers will likely for now have to be defined by us,  
as a generic framework is not complete. But we should at the very least  
lay the groundwork for using a framework, e.g. by specifying in the spec  
that Timing-Allow-Origin might also be specified by other means than this  
particular HTTP header, should the UA support such other means.

>> getResourceTimingsById should presumably return a single item, not a  
>> list?
>> Possibly the same for getResourceTimingsByLocation.
>
> An element with an id could change its source and get a second resource,  
> both of these would be included with the same id in the  
> PerformanceResourceTiming interface.

Right, this should probably be clarified in the spec, when I see DOMID, I  
immediately think of a unique entry. And since  
getResourceTimingsByLocation doesn't take wildcards, that should be a  
single item, not a list.

-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Thursday, 31 March 2011 07:53:36 UTC