Re: [Resource Timing] Why does connectEnd exclude the SSL Handshake?

Chrome includes it. We match the Navigation Timing spec.

James


On Wed, Apr 10, 2013 at 1:06 PM, Andy Davies <dajdavies@gmail.com> wrote:

> I think this might have been the discussion that led to Nav TIming
> changing -
> http://lists.w3.org/Archives/Public/public-web-perf/2010Nov/0046.html I
> also found something Karen Andersen wrote last nigh about it but the
> archive search doesn't find it now :-/
>
> Jatinder, James: On the Resource Timing front would you able to clarify
> whether IE and Chrome include the SSL handshake or not?
>
> Thanks
>
> Andy
>
>
> On 10 April 2013 17:47, Jatinder Mann <jmann@microsoft.com> wrote:
>
>>  I’ve updated the Resource Timing connectEnd definition to be more
>> consistent with the Navigation Timing connectEnd definition,
>> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#dom-performanceresourcetiming-connectend.
>> ****
>>
>> ** **
>>
>> Thanks,****
>>
>> Jatinder****
>>
>> ** **
>>
>> *From:* Arvind Jain [mailto:arvind@google.com]
>> *Sent:* Wednesday, April 10, 2013 9:15 AM
>> *To:* Nic Jansma
>> *Cc:* Austin,Daniel; James Simonsen; Andy Davies; public-web-perf@w3.org
>> *Subject:* Re: [Resource Timing] Why does connectEnd exclude the SSL
>> Handshake?****
>>
>> ** **
>>
>> Yes let's fix it. I suspect it's just an oversight - we changed the text
>> in Navigation Timing as a result of this thread:****
>>
>>  http://lists.w3.org/Archives/Public/public-web-perf/2010Nov/0046.html***
>> *
>>
>> and we probably forgot to make the change in Resource Timing
>> specification.****
>>
>> ** **
>>
>> ** **
>>
>> On Wed, Apr 10, 2013 at 8:05 AM, Nic Jansma <nic@nicj.net> wrote:****
>>
>>  NavigationTiming and ResourceTiming differ in how connectEnd is defined:
>>
>> NavigationTiming (http://www.w3c-test.org/webperf/specs/NavigationTiming/
>> ):****
>>
>> connectEnd<https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#dom-performancetiming-connectend>
>> *must include *the time interval to establish the transport connection
>> as well as other time interval such as SSL handshake and SOCKS
>> authentication. ****
>>
>> ResourceTiming (http://www.w3c-test.org/webperf/specs/ResourceTiming/):**
>> **
>>
>> ** **
>>
>> connectEnd<http://www.w3.org/TR/resource-timing/#dom-performanceresourcetiming-connectend>must include the time interval to establish the transport connection.
>> *It must not include other *time interval such as SSL handshake and
>> SOCKS authentication.****
>>
>>  IMO the NT spec has the better definition, as
>> secureConnectionEnd==connectEnd in this case (which is why
>> secureConnectionEnd was omitted from both of the specs).  Also, the 'TCP'
>> phase in the images in both NT and RT specs shows connectEnd including
>> SSL/SOCKS.
>>
>>
>>
>> ****
>>
>> - Nic****
>>
>> http://nicj.net/****
>>
>> @NicJ****
>>
>>  On 4/10/2013 10:45 AM, Austin,Daniel wrote:****
>>
>>  There is no such animal as 'SecureConnectionEnd', in either nav or res
>> timing. It's a significant flaw in the model. Also missing are details
>> about the underlying OCSP calls. This significantly reduces the utility of
>> the spec, IMHO.****
>>
>> ** **
>>
>> R,****
>>
>> D-
>>
>> Sent from my iPhone****
>>
>>
>> On Apr 10, 2013, at 3:56 AM, "James Simonsen" <simonjam@google.com>
>> wrote:****
>>
>>  I can only guess it's because that's covered by sslConnectStart/End.
>> But in the case of browsers that don't provide that, it seems like they
>> should fall back to including it connectStart/End. Anyone else have an
>> opinion? ****
>>
>> ** **
>>
>> James****
>>
>> ** **
>>
>> On Tue, Apr 9, 2013 at 12:16 PM, Andy Davies <dajdavies@gmail.com> wrote:
>> ****
>>
>>  I understand why the spec states that connectEnd excludes SOCKS
>> authentication etc., but don't quite understand why it excludes the SSL
>> Handshake****
>>
>> ** **
>>
>> "connectEnd must include the time interval to establish the transport
>> connection. It must not include other time interval such as SSL handshake
>> and SOCKS authentication."****
>>
>> ** **
>>
>> I've had a hunt back through the archives but I couldn't find any
>> reference as to why.****
>>
>> ** **
>>
>> Is anyone able to explain?
>>
>> Thanks
>>
>> Andy****
>>
>>  ** **
>>
>>  ** **
>>
>>  ** **
>>
>
>