Link header support

[Yoav Weiss]

Hi,

I've been recently playing around with the addition of "Link" header support in Blink. My goal was to see how hard it would be to add those, and I'll send an "intent to implement/ship" for those features once I'd know that I can commit to seeing them through.

One thing I noticed is that the support for Link headers that was built as part of the Navigation Transitions feature is not in Blink, but in content/browser. While that may make sense for that feature, it makes less sense for the other features that would rely on Link, mainly Resource Hints and Preload (as well as the current non-standard equivalent features).

Would there be an interest in moving that functionality to Blink also for Nav transitions, and have a single location where Link headers are parsed?

Cheers,

Yoav

[Chris Bentzel]

+net-dev

To me it's unclear if we want to handle preload/prefetch/resource hint
link headers in Blink or outside of it.

Most of the processing is done in the Chrome layer, especially since
there's no error feedback mechanism to link elements this way.

[Chris Bentzel]

Or, I guess not Chrome layer but content as well as net layer to some degree.

[Yoav Weiss]

On Wed, Dec 17, 2014 at 3:37 PM, Chris Bentzel <cben...@chromium.org> wrote:

Or, I guess not Chrome layer but content as well as net layer to some degree.

On Wed, Dec 17, 2014 at 9:37 AM, Chris Bentzel <cben...@chromium.org> wrote:
> +net-dev
>
> To me it's unclear if we want to handle preload/prefetch/resource hint
> link headers in Blink or outside of it.
>
> Most of the processing is done in the Chrome layer, especially since
> there's no error feedback mechanism to link elements this way.

In my view, adding that functionality in Blink would make it easier to add more "Link:" based features in the future. Examples include external stylesheets (supported by Firefox, but for which I don't see a huge use-case), HTML imports and NavTransitions exit styles.

Also - I may be wrong, but I think it'd make it easier to support CSP for resources fetched by these headers.

[David Benjamin]

On Wed Dec 17 2014 at 10:28:35 AM Yoav Weiss <yo...@yoav.ws> wrote:

Also - I may be wrong, but I think it'd make it easier to support CSP for resources fetched by these headers.

I'm not familiar enough with navigation transitions to have opinions on whether it more naturally belongs on the browser or renderer side of the divide (at a glance, it's currently browser-side), but we'll need to able to process some of CSP browser-side anyway. It's needed for enforcing CSP right in sendBeacon and PlzNavigate (and I think part of OOPIF too?) where there may not be a renderer to run the check in at all.

David

 

> On Wed, Dec 17, 2014 at 4:46 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>> Hi,
>>
>> I've been recently playing around with the addition of "Link" header support
>> in Blink. My goal was to see how hard it would be to add those, and I'll
>> send an "intent to implement/ship" for those features once I'd know that I
>> can commit to seeing them through.
>>
>> One thing I noticed is that the support for Link headers that was built as
>> part of the Navigation Transitions feature is not in Blink, but in
>> content/browser. While that may make sense for that feature, it makes less
>> sense for the other features that would rely on Link, mainly Resource Hints
>> and Preload (as well as the current non-standard equivalent features).
>>
>> Would there be an interest in moving that functionality to Blink also for
>> Nav transitions, and have a single location where Link headers are parsed?
>>
>> Cheers,
>> Yoav

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACj%3DBEhNJeDpLf3Ob%2BKYFdS43cSRpsRcySdzv4vNkNz%3Dz-hDYg%40mail.gmail.com.

[Oystein Eftevaag]

The main purpose of navigation transitions is to hide latency, so it's pretty imperative that it's handled as soon as possible rather than after a renderer is started (which could involve starting a new process and might be hundreds of milliseconds after HTTP headers are received). 

It seems natural that this would also apply to preload/prefetch/resource hint link headers, or much/all of the benefit would be lost compared to just using normal preload/prefetch <link> elements early in the HTML resource.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[David Benjamin]

Note that we currently don't start fetching the main resource under after the renderer is spawned anyway. (Long-term, that's changing with PlzNavigate since the current navigation path is somewhat inverted from what it should be.)

[Yoav Weiss]

On Thu, Dec 18, 2014 at 12:34 AM, David Benjamin <davi...@chromium.org> wrote:

Note that we currently don't start fetching the main resource under after the renderer is spawned anyway. (Long-term, that's changing with PlzNavigate since the current navigation path is somewhat inverted from what it should be.)

On Thu Dec 18 2014 at 6:27:42 PM Oystein Eftevaag <oyst...@google.com> wrote:

The main purpose of navigation transitions is to hide latency, so it's pretty imperative that it's handled as soon as possible rather than after a renderer is started (which could involve starting a new process and might be hundreds of milliseconds after HTTP headers are received). 

It seems natural that this would also apply to preload/prefetch/resource hint link headers, or much/all of the benefit would be lost compared to just using normal preload/prefetch <link> elements early in the HTML resource.

Hundreds of milliseconds certainly sound like a good reason to place all Link header handling on the browser side.

OTOH, since these headers come in after multiple network RTTs (and I'm guessing the renderer's creation starts as soon as we know the navigation will take place, and possibly even sooner), I wonder what the difference here would be in practice, after the main resource fetching fixes.

On Wed, Dec 17, 2014 at 6:20 PM, David Benjamin <davi...@chromium.org> wrote:

On Wed Dec 17 2014 at 10:28:35 AM Yoav Weiss <yo...@yoav.ws> wrote:

Also - I may be wrong, but I think it'd make it easier to support CSP for resources fetched by these headers.

I'm not familiar enough with navigation transitions to have opinions on whether it more naturally belongs on the browser or renderer side of the divide (at a glance, it's currently browser-side)

As far as I can tell NavTransitions "transition-entering-stylesheet" is on the browser side (using Link headers) and the "transition-exit-stylesheet" is on the Blink side using <link> tags.

From an authoring perspective, I think it'd be better to have support for both headers and tags on both parts, regardless of the code's location.

   

, but we'll need to able to process some of CSP browser-side anyway. It's needed for enforcing CSP right in sendBeacon and PlzNavigate (and I think part of OOPIF too?) where there may not be a renderer to run the check in at all.

 

Great, so we probably shouldn't take CSP support into consideration here. Do you have an idea on when CSP support on the browser-side will happen?

[Mike West]

On Thu, Dec 18, 2014 at 10:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

  

, but we'll need to able to process some of CSP browser-side anyway. It's needed for enforcing CSP right in sendBeacon and PlzNavigate (and I think part of OOPIF too?) where there may not be a renderer to run the check in at all.

 

Great, so we probably shouldn't take CSP support into consideration here. Do you have an idea on when CSP support on the browser-side will happen?

I've been planning on poking at that once we merge the repositories, which looks like it actually might happen again. :)

-mike

[Oystein Eftevaag]

On Thu, Dec 18, 2014 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 18, 2014 at 12:34 AM, David Benjamin <davi...@chromium.org> wrote:

Note that we currently don't start fetching the main resource under after the renderer is spawned anyway. (Long-term, that's changing with PlzNavigate since the current navigation path is somewhat inverted from what it should be.)

On Thu Dec 18 2014 at 6:27:42 PM Oystein Eftevaag <oyst...@google.com> wrote:

The main purpose of navigation transitions is to hide latency, so it's pretty imperative that it's handled as soon as possible rather than after a renderer is started (which could involve starting a new process and might be hundreds of milliseconds after HTTP headers are received). 

It seems natural that this would also apply to preload/prefetch/resource hint link headers, or much/all of the benefit would be lost compared to just using normal preload/prefetch <link> elements early in the HTML resource.

Hundreds of milliseconds certainly sound like a good reason to place all Link header handling on the browser side.

OTOH, since these headers come in after multiple network RTTs (and I'm guessing the renderer's creation starts as soon as we know the navigation will take place, and possibly even sooner), I wonder what the difference here would be in practice, after the main resource fetching fixes.

It should be easy enough to test, at that point. It may well be that the biggest difference comes from sites with chunked responses; seeing a fair bit of delay between headers and HTML isn't uncommon.

On Wed, Dec 17, 2014 at 6:20 PM, David Benjamin <davi...@chromium.org> wrote:

On Wed Dec 17 2014 at 10:28:35 AM Yoav Weiss <yo...@yoav.ws> wrote:

Also - I may be wrong, but I think it'd make it easier to support CSP for resources fetched by these headers.

I'm not familiar enough with navigation transitions to have opinions on whether it more naturally belongs on the browser or renderer side of the divide (at a glance, it's currently browser-side)

As far as I can tell NavTransitions "transition-entering-stylesheet" is on the browser side (using Link headers) and the "transition-exit-stylesheet" is on the Blink side using <link> tags.

From an authoring perspective, I think it'd be better to have support for both headers and tags on both parts, regardless of the code's location.

Absolutely, that's always been the end goal. The complicating factor here is that the renderer of the previous site (the exiting document) needs to still be alive at the point where we apply the transition-entering-stylesheet to the transition layer, so that we can apply its exiting transitions, and that puts limits on how far ahead in terms of parsing we can go for the incoming document.

 

   

, but we'll need to able to process some of CSP browser-side anyway. It's needed for enforcing CSP right in sendBeacon and PlzNavigate (and I think part of OOPIF too?) where there may not be a renderer to run the check in at all.

 

Great, so we probably shouldn't take CSP support into consideration here. Do you have an idea on when CSP support on the browser-side will happen?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yoav Weiss]

On Thu, Dec 18, 2014 at 8:17 PM, 'Oystein Eftevaag' via blink-dev <blin...@chromium.org> wrote:

On Thu, Dec 18, 2014 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 18, 2014 at 12:34 AM, David Benjamin <davi...@chromium.org> wrote:

Note that we currently don't start fetching the main resource under after the renderer is spawned anyway. (Long-term, that's changing with PlzNavigate since the current navigation path is somewhat inverted from what it should be.)

On Thu Dec 18 2014 at 6:27:42 PM Oystein Eftevaag <oyst...@google.com> wrote:

The main purpose of navigation transitions is to hide latency, so it's pretty imperative that it's handled as soon as possible rather than after a renderer is started (which could involve starting a new process and might be hundreds of milliseconds after HTTP headers are received). 

It seems natural that this would also apply to preload/prefetch/resource hint link headers, or much/all of the benefit would be lost compared to just using normal preload/prefetch <link> elements early in the HTML resource.

Hundreds of milliseconds certainly sound like a good reason to place all Link header handling on the browser side.

OTOH, since these headers come in after multiple network RTTs (and I'm guessing the renderer's creation starts as soon as we know the navigation will take place, and possibly even sooner), I wonder what the difference here would be in practice, after the main resource fetching fixes.

It should be easy enough to test, at that point. It may well be that the biggest difference comes from sites with chunked responses; seeing a fair bit of delay between headers and HTML isn't uncommon.

Oh, the renderer can't get the headers until some of the HTML content started arriving? If that's the case, I'm convinced handling should be browser side.

[Oystein Eftevaag]

On Thu, Dec 18, 2014 at 5:24 PM, Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 18, 2014 at 8:17 PM, 'Oystein Eftevaag' via blink-dev <blin...@chromium.org> wrote:

On Thu, Dec 18, 2014 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 18, 2014 at 12:34 AM, David Benjamin <davi...@chromium.org> wrote:

Note that we currently don't start fetching the main resource under after the renderer is spawned anyway. (Long-term, that's changing with PlzNavigate since the current navigation path is somewhat inverted from what it should be.)

On Thu Dec 18 2014 at 6:27:42 PM Oystein Eftevaag <oyst...@google.com> wrote:

The main purpose of navigation transitions is to hide latency, so it's pretty imperative that it's handled as soon as possible rather than after a renderer is started (which could involve starting a new process and might be hundreds of milliseconds after HTTP headers are received). 

It seems natural that this would also apply to preload/prefetch/resource hint link headers, or much/all of the benefit would be lost compared to just using normal preload/prefetch <link> elements early in the HTML resource.

Hundreds of milliseconds certainly sound like a good reason to place all Link header handling on the browser side.

OTOH, since these headers come in after multiple network RTTs (and I'm guessing the renderer's creation starts as soon as we know the navigation will take place, and possibly even sooner), I wonder what the difference here would be in practice, after the main resource fetching fixes.

It should be easy enough to test, at that point. It may well be that the biggest difference comes from sites with chunked responses; seeing a fair bit of delay between headers and HTML isn't uncommon.

Oh, the renderer can't get the headers until some of the HTML content started arriving? If that's the case, I'm convinced handling should be browser side.

I was thinking more about the difference between link headers vs. <link> elements in this case, sorry, confusing even myself to some degree here :). I'm actually not sure; it'd regardless be interesting to have UMA metrics on the latency between headers are visible to the browser and when they're visible to Blink, it's hard to get an overview of how long this can take in practice.

[David Benjamin]

On Fri Dec 19 2014 at 5:38:44 PM Oystein Eftevaag <oyst...@google.com> wrote:

On Thu, Dec 18, 2014 at 5:24 PM, Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 18, 2014 at 8:17 PM, 'Oystein Eftevaag' via blink-dev <blin...@chromium.org> wrote:

On Thu, Dec 18, 2014 at 4:14 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Dec 18, 2014 at 12:34 AM, David Benjamin <davi...@chromium.org> wrote:

Note that we currently don't start fetching the main resource under after the renderer is spawned anyway. (Long-term, that's changing with PlzNavigate since the current navigation path is somewhat inverted from what it should be.)

On Thu Dec 18 2014 at 6:27:42 PM Oystein Eftevaag <oyst...@google.com> wrote:

The main purpose of navigation transitions is to hide latency, so it's pretty imperative that it's handled as soon as possible rather than after a renderer is started (which could involve starting a new process and might be hundreds of milliseconds after HTTP headers are received). 

It seems natural that this would also apply to preload/prefetch/resource hint link headers, or much/all of the benefit would be lost compared to just using normal preload/prefetch <link> elements early in the HTML resource.

Hundreds of milliseconds certainly sound like a good reason to place all Link header handling on the browser side.

OTOH, since these headers come in after multiple network RTTs (and I'm guessing the renderer's creation starts as soon as we know the navigation will take place, and possibly even sooner), I wonder what the difference here would be in practice, after the main resource fetching fixes.

It should be easy enough to test, at that point. It may well be that the biggest difference comes from sites with chunked responses; seeing a fair bit of delay between headers and HTML isn't uncommon.

Oh, the renderer can't get the headers until some of the HTML content started arriving? If that's the case, I'm convinced handling should be browser side.

I was thinking more about the difference between link headers vs. <link> elements in this case, sorry, confusing even myself to some degree here :). I'm actually not sure; it'd regardless be interesting to have UMA metrics on the latency between headers are visible to the browser and when they're visible to Blink, it's hard to get an overview of how long this can take in practice.

Note that these metrics will be very dependent on our current navigation architecture which will hopefully change long-term. In the PlzNavigate future, at the point the headers are known to the browser, the renderer may not even have been started yet; until we know the response is not a redirect or a download, it's premature to select a renderer. (Right now we select the renderer first thing and have to do awkward contortions browser-side to account for redirects between sites. Also network requests cannot start until the renderer has been initialized, which we also intend to change)

That said, we'll be predictively spawning the renderer ahead of time, since most of the time you won't have a redirect, and we should pay for renderer startup and the network in parallel.

+Camille Lamy​ , +Carlos Knippschild​

David

[Carlos Knippschild]

tl;dr: we will create a new renderer as soon as possible, update (trash and create a new one) it as redirects happen, but it might be discarded in the end if it doesn't make sense to use it.

Just confirming and clarifying what David said about the changes for when PlzNavigate is enabled:

• We will speculatively create a new renderer as soon as possible after a navigation request is received at the browser if the URL's site is incompatible with the current one's site.
• For every redirect that invalidates the speculative renderer, we destroy it and create a new one (again following the same rule regarding the current renderer's site).
• If finally the navigation doesn't require a new renderer (it's a download) we trash it and are done.
• if it ends up at the same site of the current renderer, we trash the speculative and are done.
• Otherwise we switch the speculative in and discard the current one.

[Yoav Weiss]

On Fri, Dec 19, 2014 at 6:01 AM, 'Carlos Knippschild' via blink-dev <blin...@chromium.org> wrote:

tl;dr: we will create a new renderer as soon as possible, update (trash and create a new one) it as redirects happen, but it might be discarded in the end if it doesn't make sense to use it.

Just confirming and clarifying what David said about the changes for when PlzNavigate is enabled:

• We will speculatively create a new renderer as soon as possible after a navigation request is received at the browser if the URL's site is incompatible with the current one's site.
• For every redirect that invalidates the speculative renderer, we destroy it and create a new one (again following the same rule regarding the current renderer's site).
• If finally the navigation doesn't require a new renderer (it's a download) we trash it and are done.
• if it ends up at the same site of the current renderer, we trash the speculative and are done.
• Otherwise we switch the speculative in and discard the current one.

Are there any predicted time frames for when these changes will be implemented (even if not turned on by default)? If it's not too far away, we could use it to measure the time differences we're interested in on a synthetic benchmark, and see if this should be a consideration to the location of the Link header features.  

[Carlos Knippschild]

The estimate for final delivery is Q2 2015. Currently it's in not in a usable state but my guess is that we might have enough done by the end of Q1 to allow for testing.