Re: [JSPreflight] An alternate approach

Hi Mike,

I think I like the idea, need to ponder it a bit more but in the meantime a
few comments and questions:

1. ResourceTiming API is supported in IE10 and Chrome
2. Is there a standard for key/value pairs in headers?  X-Timing-Measures
proposes : ; for assignment and separation whereas  Client-Hints proposes =
,
3. I can see a lot of use for this with Nav and User Timing, not so sure
about Resource Timing due to the potential volume of data (but if it's
configurable that may not matter)
4. Will the response always be returned via POST - one advantage of GET is
people can just have a beacon server that returns a gif or a HTTP 204 and
(in really cheap solutions) the timing data scooped out of the HTTPD
logfiles.

Andy



On 9 September 2013 14:45, McCall, Mike <mmccall@akamai.com> wrote:

> Hi,
>
> Since the JSPreflight spec was announced, there has been some very good,
> and heated, debate about its merits.  While I think the idea's heart is in
> the right place, I agree with many of Ilya Gregorik's concerns about it -
> in particular those regarding security and the effect it may have on
> performance.
>
> >From what I've gathered from the spec and subsequent discussion, it seems
> there's a desire to collect analytics data without needing to modify the
> page's HTML.  With that in mind, I'd like to point out a proposal[1] that
> I had drafted during the HTTP 2.0 discussions a year or so ago, as an
> alternative or perhaps a complement to the JSPreflight spec.
>
> While it can be refined more for this audience, the crux of idea is that:
>
> - A server and user agent negotiate a set of measurements to collect
> - The UA collects the measurements, and sends them back to the server
>
> The semantics of how this is done can and probably should be changed from
> their current state.  In particular, the proposal below uses HTTP headers
> for much of the heavy lifting, whereas we might be able to refine it to
> just have the UA send back the whole Performance Timeline[2], and/or
> leverage the Beacon API[3] to send back data.
>
> Thoughts?
>
> Mike
>
> 1. http://tools.ietf.org/html/draft-mccall-httpbis-timing-measurements-00
> 2. http://www.w3.org/TR/performance-timeline/
> 3. https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html
>
>
>