Re: Proposal to measure end-user latency

I suppose the question here then is how much better these (client-side)
measurements are as compared to what the server can observe and generate on
its own, and what attack vectors this information might possibly
allow/enhance.
On Sep 4, 2013 5:46 AM, "Sébastien BARNOUD" <sebastien.barnoud@prologism.fr>
wrote:

> My proposal wasn't to have an interaction between the application layer
> and the protocol. So, I also agree.
>
> My proposal is to have an optional measurement at the protocol level
> itself. Uses cases could be for protocols over HTTP, like SOAP to have
> automatically a minimal set of measurements without extra coding at
> application layer.
> Of course, it will be available for a HTML application that doesn't
> implement any measurement at the application layer which, although it is
> regrettable, is often the case.
>
> However, it is true that a protocol is not there to overcome all the
> misery of the world.
>
>
> Le 04/09/13 07:00, « Willy Tarreau » <w@1wt.eu> a écrit :
>
> >On Tue, Sep 03, 2013 at 03:56:49PM -0700, Roberto Peon wrote:
> >> I'd imagine that you'd want to re-use the same timing information that
> >>is
> >> collectable within the javascript, and likely in the same format (that
> >>just
> >> makes sense from an engineering perspective).
> >> That format and when each of the timestamps is collected is currently
> >> defined in the W3C.
> >>
> >> I'd just ask them to trigger the collection of that data collection upon
> >> the condition stated in the header.
> >> The interaction with HTTP would just be to add that header to the IANA
> >> registry, if so... doesn't seem very likely to require this WG.
> >
> >If it'd be done that way, I totally agree.
> >
> >Cheers,
> >Willy
> >
>
>
>