Send preload request headers

[bencroker]

For the preload extension to work as intended, the Cache-Control response header must explicitly allow the browser to cache responses. For example, if the response contains Cache-Control: no-cache, then preloading essentially becomes redundant, whereas returning Cache-Control: private, max-age=60 tells the browser that it may cache the response for up to 60 seconds (added to the docs in #1741), which leads to the extension working as expected.

There’s currently, however, no way for the server to know that this is a preload request. If a HX-Preload header was sent with requests that originate from elements with the preload attribute then the server would be able to respond with the appropriate Cache-Control headers.

For even more control, it might make sense to add a hx-cache attribute that tells the server how long it would like to cache the response for.

<div hx-ext="preload">
    <button hx-get="" hx-cache="60" preload><button>
</div>

Of course it’s still up to the server whether to respect this value or not.

Any thoughts on whether this could add value and what approach might be most suitable @benpate @1cg @alexpetros?

[Telroshan]

I like the HX-Preload header, I'm a bit more skeptical about that hx-cache attribute though I must admit

It seems like this would be sent as a standard parameter right?
That the server would pass and respect or not in the Cache-Control header it would send back.

As such, I would say that the existing ways of sendings parameters are already enough to fill that part:

• a URL query param (for ex hx-get="/url?cache=60")
• a hidden input to carry a name="cache" value="60", inside a form or included with hx-include
• The hx-vals attribute (or its deprecated counterpart hx-vars)

Also given that, the existing options would allow you naming that cache parameter as you wish, it seems to me that hx-cache would only add more constraints, without adding much more value

So to sum up, I fully agree for the HX-Preload header, makes perfect sense, but I would doubt that the hx-cache adds much value / makes much sense, given the existing options to send such a parameter to the server

[Telroshan]

Giving a second thought to this, maybe you meant sending it as the value of the HX-Preload header, and not a standard URL/body param @bencroker ? It seems I had forgotten that headers could have values, my bad

In which case, the hx-cache would make perfect sense to me, though I would probably suggest naming it more explicitly such as hx-preload-cache, as I think it could be unintuitive at first glance when reading some code, that the cache is meant solely for preload and not for any htmx request

[bencroker]

Giving a second thought to this, maybe you meant sending it as the value of the HX-Preload header, and not a standard URL/body param @bencroker ?

I wasn’t suggesting any particular implementation, just the attribute, the value of which could of course take the form of a request header value.

In which case, the hx-cache would make perfect sense to me, though I would probably suggest naming it more explicitly such as hx-preload-cache, as I think it could be unintuitive at first glance when reading some code, that the cache is meant solely for preload and not for any htmx request

I think distinguishing a hx-cache attribute from the preload attribute could make sense as there maybe cases where you want to cache a response but not necessarily preload it.

I agree with your argument that it is already possible to send a request for a cache header in various forms (as a param, header value, etc.). I was just floating the idea of standardising this.

Nevertheless, the primary topic up for discussion is a new HX-Preload header. I know that I’ll have to implement some way of letting the server know which responses to cache, which was the rationale for some standardised way of indicating that.