RE: About ResourceTiming API and Page errors

Hi Ricardo,

Thanks for your feedback!  

For determining errors in each stage of the download, I think the spec already gives a way to detect errors.  We have both start and end timestamps for each phase, and any phase that isn't reached -- due to errors or otherwise -- will have a timestamp of 0.  If you have a start timestamp for a phase but the end timestamp is 0, it could indicate that the phase had an error (say TCP connect failed, so connectEnd would be 0).  For your example of the beginning of a HTTP response being received but the TCP connection disconnects before it's finished, the responseStart attribute would be a valid timestamp and responseEnd would be 0.  You should be able to detect errors in the various phases by these zero'd timestamps -- can you think of a scenario where you wouldn't be able to detect an error?

We had discussed the possibility of exposing the HTTP status code a while back, and decided against it for a couple of reasons:
* You would never see a 301/302 redirect code as we would always report the "final" resource's status code
* A 304 would indicate the content is already in the user's cache, which would leak privacy information, so we wouldn't be able to report it or would have to lie
* If we're only going to report success 2xx and error 4xx/5xx codes, and can't report 304, we could possibly have just a "successful" attribute.  But we didn't think that would be very useful, and we'd have to do a security/privacy review as this information hasn't been exposed before.

I can't remember all of the discussion points at the moment - others may be able to chime with their thoughts.

- Nic


-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Ricardo Oliveira
Sent: Thursday, June 30, 2011 12:14 PM
To: public-web-perf@w3.org
Subject: About ResourceTiming API and Page errors

Hello All,

I was just glancing at the ResourceTiming API spec here:
http://dvcs.w3.org/hg/webperf/raw-file/f1abd45b5641/specs/ResourceTiming/Overview.html

And i've just noticed that there's not any fields to signal errors in each stage of the component processing. This is also a caveat of HAR v1.2. Basically performance information is mixed with cases where there are errors. In the case of HAR lack of data for a stage (e.g. DNS) is signaled with -1, but that does not necessarily indicate that there was an error in the component, it just indicated there's no data for that stage. I've seen people hacking into HAR and adding extra error fields to encode error conditions.  Also sometimes there's a value in the field but the stage was not completed due to an error so it doesnt make much sense to use that value. This can happen after the Http response is received but e.g. the TCP connection gets broken meanwhile.

I think the main thing is to being able to separate performance from availability, and have explicit fields for errors along with the performance fields. These can be a combination of an error flag and text-free fields due to the entropy between different browsers. Also, there should be a HTTP status field to separate filter 500 cases, etc

Just wanted to toss this at the group and see what you guys think,

Cheers

--Ricardo

Received on Tuesday, 12 July 2011 20:29:54 UTC