PerformanceResourceTiming: secureConnectionStart

[avadacatavra]

In components/net/http_loader.rs::http_fetch we need to set secure_connection_start (if we're using a persistent connection). Otherwise, we can probably use components/net/connector.rs for this

On getting, the secureConnectionStart attribute MUST return as follows:

1. The same value as fetchStart, if a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources.
2. The time immediately before the user agent starts the handshake process to secure the current connection, if a secure transport is used and the last non-redirected fetch of the resource passes the timing allow check algorithm.
3. zero, otherwise.

Spec: https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-secureconnectionstart

[highfive]

Hi! If you have any questions regarding this issue, feel free to make a comment here, or ask it in the #servo channel in IRC.

If you intend to work on this issue, then add @highfive: assign me to your comment, and I'll assign this to you. 😄

[verma-varsha]

@highfive: assign me

[highfive]

Hey @verma-varsha! Thanks for your interest in working on this issue. It's now assigned to you!

[jdm]

@verma-varsha Are you still working on this?

[wlgranados]

@highfive assign me

[highfive]

Hey @wlgranados! Thanks for your interest in working on this issue. It's now assigned to you!

[jdm]

@wlgranados Have you made any progress? Do you have any questions?

[jdm]

Unassigning due to lack of activity.

[suhasesturi]

I would like to take this up, but didn't understand the requirement correctly.

secureConnectionStart is part of PerformanceResourceTiming and this is being used nowhere in http_loader.rs

Can someone give some context pls? @jdm?

[tomasdivito]

@suhasesturi I think the idea would be add secureConnectionStart to PerformanceResourceTiming and add the according logic to setAttribute in /net_traits/lib.rs kinda how other issues seem to make for the other properties of PerformanceResourceTiming 🤔 (just looked gave it a little glance, I'm sure there a couple more things to it...)

Honestly if you want to try it go for it, I don't know much more than you about the project, if you decide not to do it I'm also interested, and even open to do it together if that could be an option 👍

[jdm]

Our network stack does not have the ability to tell us precisely when the secure connection was initiated right now. We can approximate it by using the same value as requestStart when we're fetching an HTTPS URL, and setting it to 0 otherwise. @tomasdivito's comment is correct in all other respects.

[tomasdivito]

Ok, let's try this out :) @highfive assign me

[highfive]

Hey @tomasdivito! Thanks for your interest in working on this issue. It's now assigned to you!

[tomasdivito]

I have some doubts regarding this task @jdm maybe you can clarify me how to get cerain information in the code or if I should add something to get them 🤔

• We should return Zero when we fail the Timing Allow Check which is currently under development, and it looks like when we set the Timing Allow Check alg as failed we are setting all the values as zero (as we should) and probably we should only add a TODO to add the declaration of secure_connection_start = 0 as the rest of the setAttribute is enclosed by a check for the value of the Timing Allow Check and if it fails we will just end end there if I got the spec right. (ref to what I'm talking about in #23822

• How can I know if we are currently on a persistent connection? to apparently same the value the same as fetchStart? and shouldn't we assign it using precise_time_ns() regardless based on what the step 15 says here? I got confused by reading this because basically it seems like we would just check for the Timing Allow Check or else we just set it to the time just before the handshake is done (which I'm not really sure where this is happening)

Sorry if this are too many questions for the issue, I'm really interested on understanding more about how this works and it's the first time looking at this codebase :)

[jdm]

The timing allow check code is responsible for setting any existing timings to 0 and preventing any further ones from being set, so you can ignore it for the purposes of this issue. Since there is no way to tell if there's a persistent connection right now, you can add a TODO comment for it and ignore it.