exposing protocol used to fetch object in javascript

[Shakesh Jain]

Hello,

We, at Akamai, are working on using real-user monitoring (RUM) to
measure server's,
SPDY vs. HTTP, performance. With variety of protocols (http/spdy2/spdy3)
in use it is hard to figure out how many components were fetched over what
protocol in a given page and that makes it hard to understand/trust
performance measurement results without digging deep into what is on the
page.

So far we know that, Chrome sets a flag which can be accessed from
Javascript whenever html is fetched over SPDY and Firefox adds a response
header which indicates the protocol used to fetch an object. Not sure if
other browsers expose this information in some way or the other but would
love to find out.

Ideally, it would be really nice if browsers can expose a way to iterate
over all objects on a page and find out protocol used to fetch, in
Javascript. This is similar to exposing resource timing information
(http://www.w3.org/TR/resource-timing/).

Please let us know what folks here think.

Regards,
Shakesh

[Mike Belshe]

+1.

How about an addition to the PerformanceResourceTiming object for wasFetchedViaSpdy ?

Mike

[William Chan (陈智昌)]

I see you're from Akamai, so this makes sense now. Rajeev mentioned
this as a topic for the HTTP/2 discussion. Like Mike, I think the idea
is reasonable, although I'm hesitant to standardize on SPDY since
HTTP/2 is of course the way forward long-term. I think it's reasonable
short-term for us to agree with other browser implementations (just
Firefox I guess) to put something in an agreed upon place so
developers could rely on it in the interim period. But there would not
be any long-term promise here, since SPDY is going to die and evolve
into HTTP/2.

> --
>
>
>

[Shakesh]

Hi Mike, Will,

Thanks for your response.

On Jan 24, 2013, at 8:16 PM, William Chan (陈智昌) <will...@chromium.org> wrote:

> I see you're from Akamai, so this makes sense now. Rajeev mentioned
> this as a topic for the HTTP/2 discussion. Like Mike, I think the idea
> is reasonable, although I'm hesitant to standardize on SPDY since
> HTTP/2 is of course the way forward long-term. I think it's reasonable
> short-term for us to agree with other browser implementations (just
> Firefox I guess) to put something in an agreed upon place so
> developers could rely on it in the interim period. But there would not
> be any long-term promise here, since SPDY is going to die and evolve
> into HTTP/2.
>

Yes, I agree, long-term we don't want this information for SPDY only. Ideally, it would be great if we can come up with a way to make this information available irrespective of protocol because even with HTTP/2 not all objects on a page will be using HTTP/2. So we are thinking of pursuing this on w3c as well and see what is the interest there.

But as a short-term solution it would be great if we can get agreement on something for SPDY.

Patrick, what do you think?

> On Thu, Jan 24, 2013 at 7:56 PM, Mike Belshe <mbe...@chromium.org> wrote:
>>
>>
>> On Fri, Jan 18, 2013 at 12:39 AM, Shakesh Jain <sha...@gmail.com> wrote:
>>>
>>> Ideally, it would be really nice if browsers can expose a way to iterate
>>> over all objects on a page and find out protocol used to fetch, in
>>> Javascript. This is similar to exposing resource timing information
>>> (http://www.w3.org/TR/resource-timing/).
>>
>>
>> +1.
>>
>> How about an addition to the PerformanceResourceTiming object for
>> wasFetchedViaSpdy ?

It would be great if this object is not SPDY specific in long-term and I like Will's suggestion of agreeing on something in short term. And we will try and see if we can standardize on putting something in PerformanceResourceTiming as long-term solution.

Thank you again for your suggestions as this is something really important for us when rolling out new protocol support for our customers.

Shakesh

[Ilya Grigorik]

On Sat, Jan 26, 2013 at 12:02 PM, Shakesh <sha...@gmail.com> wrote:

Yes, I agree, long-term we don't want this information for SPDY only. Ideally, it would be great if we can come up with a way to make this information available irrespective of protocol because even with HTTP/2 not all objects on a page will be using HTTP/2. So we are thinking of pursuing this on w3c as well and see what is the interest there.

chrome.loadTimes().npnNegotiatedProtocol

Above will return a string (spdy/v2, spdy/v3, etc) for top page. The
benefit is that its not tied to SPDY - although in practice NPN is only
used for SPDY today...

Having a generic `resource.negotiatedProtocol` seems like a good addition to pitch to W3C.

ig

[Hasan Khalil]

On Saturday, January 26, 2013, Ilya Grigorik wrote:

On Sat, Jan 26, 2013 at 12:02 PM, Shakesh <sha...@gmail.com> wrote:

Yes, I agree, long-term we don't want this information for SPDY only. Ideally, it would be great if we can come up with a way to make this information available irrespective of protocol because even with HTTP/2 not all objects on a page will be using HTTP/2. So we are thinking of pursuing this on w3c as well and see what is the interest there.

chrome.loadTimes().npnNegotiatedProtocol

Above will return a string (spdy/v2, spdy/v3, etc) for top page. The
benefit is that its not tied to SPDY - although in practice NPN is only
used for SPDY today...

Minor nit: Unless there is some translation going on in Chrome that I don't know about, that should read "spdy/2" and "spdy/3". 

 

Having a generic `resource.negotiatedProtocol` seems like a good addition to pitch to W3C.

ig

--
 
 
 

--
    -Hasan

[Patrick McManus]

On Sat, Jan 26, 2013 at 3:02 PM, Shakesh <sha...@gmail.com> wrote:

Patrick, what do you think?

I think something in resource timing probably makes the most sense. Better forums are probly whatwg or w3c - not primarily my baliwick but I can pitch in if cc'd. You can cc sic...@mozilla.com to get jonas's take.

-Pat