Automatically set Link header for each stylesheet and script

[casperisfine]

elements can be serialized in Link headers to allow the browser to preload them before it parsed the HTML body.

It is particularly useful for scripts included at the bottom of the document.

Implementation

This piggy backs on Early Hints as they are fundamentally the same feature, Early Hint simply tell the browser in advance what the Link header is likely to look like.

In term of serialization, we can either send multiple Link headers, or set multiple comma separated values in a single header. I chose the later as it's a bit more compact.

cc @eileencodes @tenderlove since you implemented early hints, you might have an opinion on this.
cc @rafaelfranca

[eileencodes]

Sorry I missed this awhile back! Looks good, thanks!

[casperisfine]

Thanks!

[fleck]

@casperisfine @eileencodes
This is a great step forward for a fast by default experience, but there are some quirks to it the way it's currently implemented.

• if a user sets defer on a javascript tag Rails shouldn't set a preload header, that's going against what the user is aiming for

• Cloudflare and many NGINX servers are configured to convert Link headers to http2/push, but in many cases that's not a good thing. Patrick Meenan delves into why in this video: https://youtu.be/sgjxuhFQktE?t=2962
  Rails should add nopush to the link headers or make it configurable as many rails users are behind NGINX or Cloudflare servers that will push these assets with no configuration available to disable this functionality other than adding nopush https://www.nginx.com/blog/nginx-1-13-9-http2-server-push/#automatic-push https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/#disablingserverpush

[casperisfine]

@fleck both good points. I'm swamped just now, but I'll see if I can come up with something early next week, unless you beat me to it.

Causing pushes is definitely a bad idea, and if people want to do that then it should definitely be explicit.

[zavan]

Just in case anyone else bumps into this:

This header can get very large in a dev environment with a lot of assets (like the Spree admin). If you're using Apache in front of a Rails dev server, like I am (in a VM, to test how it would work in prod) the header may overflow, Apache will truncate it to less than 8KiB and possibly break the response. In my case Apache was sending an incomplete response (missing the Content-Type header), the only way to fix it was by disabling this feature in config/environments/development.rb (#40882):

config.action_view.preload_links_header = false

It's probably not a problem in production because CSS and JS will usually be concatenated into less files.

Also,

In term of serialization, we can either send multiple Link headers, or set multiple comma separated values in a single header. I chose the later as it's a bit more compact.

I don't know if sending multiple Link headers would make a difference in this case, probably not.
Maybe Rails should only send the header if it doesn't exceed a certain limit? Apache has an 8 KiB limit for the headers, for nginx it's 4-8 KiB. I can open a separate issue if this is something to be considered.

[LilyReile]

@zavan Any idea why apache chooses 8KB as the response limit?

[zavan]

@zavan Any idea why apache chooses 8KB as the response limit?

I don't know, the HTTP spec itself does not enforce or recommends a limit.
It may be related to security concerns, see https://security.stackexchange.com/a/113365/237786 and https://maxchadwick.xyz/blog/http-response-header-size-limits.

A limit is needed, for sure, so maybe they just chose 8KB a long time ago and never really changed it, even though it could be larger nowadays without problems.

Also note that this limit is for the headers only, not the entire response, of course.

[LilyReile]

@zavan Based on your links it looks like every major tech that handles HTTP imposes a limit of 8192 bytes for headers. I'm guessing this adheres to the original RFC that recommends that any such limit be a minimum of 8 KB.

[casperisfine]

I might have a patch for this: #42056

Would one of you be willing to test it?

[mjtko]

I'm happy to open a new issue/redirect to a forum to cover this if it's not suitable to add a comment/question here, but this functionality can cause an awful lot of data to get sent in headers when stylesheet_link_tag is used with a data URL.

In my use case, this is happening with rendering a PDF -- the Link header is populated with >100KiB of Base64-ed CSS which breaks clients that don't want to process headers that large! I see that #42056 will break the header down, but it seems to me like there would still be a lot of data being sent in headers that, certainly in my case, isn't needed.

Does it definitely make sense to include data URLs in the Link header? Please forgive my lack of understanding, I'm not familiar with the mechanism, or what it's intending to achieve.

[casperisfine]

Does it definitely make sense to include data URLs in the Link header?

No it doesn't that's an oversight and should be fixed.