W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2013

Re: Proposal for protocol identification

From: Nottingham, Mark <mnotting@akamai.com>
Date: Thu, 12 Dec 2013 16:13:09 -0600
To: "Aaron Heady (BING AVAILABILITY)" <aheady@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, public-web-perf <public-web-perf@w3.org>
Message-ID: <1BA72343-BA0B-4A79-A2F0-66E88DE14F17@akamai.com>
Yep, sorry. 

Sent from my iPhone

> On 13 Dec 2013, at 3:30 am, "Aaron Heady (BING AVAILABILITY)" <aheady@microsoft.com> wrote:
> 
> Your link 404'ed for me. Is this same document?
> 
> http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg 
> 
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net] 
> Sent: Wednesday, December 11, 2013 9:51 PM
> To: public-web-perf
> Subject: Proposal for protocol identification
> 
> 
> Here's a proposal for identifying the protocol in use, both in NavigationTiming and ResourceTiming:
> 
> --->8---
> 
> readonly attribute DOMString protocol;
> 
> This optional attribute reflects the protocol used to fetch the resource, as identified by the ALPN Protocol Identifier <http://tools.ietf.org/search/draft-ietf-tls-applayerprotoneg>. Its value is a DOMString representing the Protocol Identifier.
> 
> Because ALPN Protocol Identifiers are specified as arrays of bytes, this specification assumes that they will be encoded in UTF-8 or a compatible encoding; if the Protocol Identifier is not valid UTF-8, the attribute's value should be an empty string.
> 
> Note that this attribute is intended to identify the protocol in use for the fetch regardless of how it was actually negotiated; that is, even if ALPN is not used to negotiate the protocol, this attribute still uses the ALPN Protocol Identifier to indicate the protocol in use.
> 
> ---8<---
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 
Received on Thursday, 12 December 2013 22:13:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC