Early Hints, RFC and multiple headers

Looking at the Early HInts RFC it shows examples of multiple Link: response headers.

Using IIS is not possible to create multiple response headers with the same name.

According to RFC 2616 rfc2616 (ietf.org) “Hypertext Transfer Protocol – HTTP/1.1”

“Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one “field-name: field-value” pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.”

So instead of generating multiple headers, I am generating a single one with something like this:

Link: </style.css>; rel=preload; as=style , </script1.js>; rel=preload; as=script , </script2.js>; rel=preload; as=script

To anyone who has tested this already in the beta, will this work? If not, is it possible to add headers from Cloudflare UI instead of from origin?

You could use a Worker, but I am not 100% sure it would work.

Having not seen the beta yet - yeah a worker could be something… Or as I suggest could just be a list entered through the dashboard UI.

Curious to see how this will work in real life.

I doubt this will happen anytime soon, even though I would like to do the same.

A UI might get unwieldy on this. Each HTML page might have a different set of hints, and the hints could be rapidly changing. My understanding of the blog post is that the hints will be stored with the existing cached object. Storing all those hints independently of the HTML, and then doing a look-aside for every request hitting the cache to check for a list of hints could impact performance. The intention is to let the client use “server think time”, rather than spending that time on the edge doing a lookup for hints.

1 Like

Agreed, I want to see the auto hint creator AI thing :stuck_out_tongue:

Ideally the auto hin AI thing would be ideal.

If this is only good for cached objects then it would bring no benefits for dynamically-generated pages - I have mostly dynamic pages and a load of preload and preconnect statements at the beginning of the HTML to speed up things. If these could be Early Hints instead, it would speed up things as my server response for dynamic content can be anything from 300ms - 800 ms.

So even if not from the UI but from looking at previous responses for the same path, the main question is still “will a single Link header with multiple options be suitable, seeing not all servers can issue multiple headers with same name?”

When I visit the coffee site mentioned in the blog post, its pages aren’t cached. I can’t imagine Hints are only pulled from cached HTML. Maybe @michael meant that the hints are stored with the css/font/etc it hints to, though that doesn’t sound right to me, either.

I envisioned that hints would be pulled from HTML, then sent immediately as a 103 so the browser would work on it first, right before the 200 HTML response came in.

Smart Early Hints. It would be interesting to see how smart it can be. If a user is browsing around a site they probably already have the boilerplate css/js, but they might not have the hero image from the page they are now requesting, so that is a useful hint to send. Looking at referrer might give the Edge some nice information to tailor that kind of hint. Will they be smart enough to vary the hints by UA, so with Cloudflare Stream for example, Safari users might be sent a hint to load the HLS stream manifest, but other browsers will be hinted to fetch an MPEG-DASH manifest instead?

That and a dollar will get you…

In the diagram from the blog it says “2. 103 Early Hint sent from cache”. If they have to wait for a response from the Origin to know what the hints are, and the Origin does not directly support hints, then you have a Catch-22. The cache might just contain a “hit for pass” object or BYPASS, along with the hints. That is enough information to send a 103 to the client, while sending a request to the Origin.

3 Likes

highlighted bold sections

To avoid requiring origins to emit 103 responses from their origins directly, we settled on an approach that takes advantage of something many customers already used to indicate which assets an HTML page depends on, the Link: response header.

*** When Cloudflare gets a response from the origin, we will parse it for Link headers with preload or preconnect rel types. These rel types indicate to the browser that the asset should be loaded as soon as possible (preload), or that a connection should be established to the specified origin but no bytes should be transferred (preconnect).**
*** Cloudflare takes these headers and caches them at our edge, ready to be served as a 103 Early Hints payload.**
*** When subsequent requests come for that asset, we immediately send the browser the cached Early Hints response while proxying the request to the origin server to generate the full response.**
*** Cloudflare then proxies the full response from origin to the browser when it’s available.**
*** When the full response is available, it will contain Link headers (that’s how we started this whole story). We will compare the Link headers in the 200 response with the cached version to make sure that they are the most up to date. If they have changed since they’ve been cached, we will automatically purge the out-of-date Early Hints and re-cache the new ones.**

1 Like

That makes the most sense. Sad to say, though, it will probably live about as long as any other cache object. Though maybe since they’re small, Cloudflare will be able to save them for at least a day.

Someone’s recent post about doing this with a Worker might work for me, as most of my home pages are pushed to a Worker, and I might be able to put the Hints section in there.
[never mind, that was a header for Push]

The time they live on the edge will depend on the volume of requests, so for high volume traffic sites the cached 103 responses would be pretty much permanently cached.

Which is how most caching behaves. I’d hope they’d be a little more generous with hints since they’re smaller, but it does mean there will be many many more of them.

Though with their recent push to store so much more customer data (stream, images, tiered caching), they might already be heading in that direction. At this point, that about the only way to make things faster all around.

Impact won’t be much for very little traffic sites to begin with and very high traffic would already keep those early hinted/preloaded assets in cache anyway. At least CF Enterprise users have CF cache prefetch Does Cloudflare Do Prefetching? – Cloudflare Help Center - I usually just prefetch page assets which make up a page’s critical render path :smiley:

3 Likes

Back to the original question, the format I have been using (quote above and confirmed in RDF) is acceptable according to this page Link - HTTP | MDN (mozilla.org)

1 Like