Reduce Updates | Use ETags and Status Code 304

[sirinath]

Is it possible to implement a way to send ETags and also status code 304 is returned not to update the document?

[benpate]

This sounds like an excellent suggestion. In REST APIs, this small step has gone a long way to minimizing bandwidth and speeding up my apps. From the outside, it seems like it might not be too difficult to implement in HTMX itself (but I’d defer to people who actually know)

I‘m guessing there would be extra technical challenges involved on the server side. For instance, if I merge data into an online form, my server would need to verify signatures for both the form and its contents. But, that’s a server-side concern that’s probably out of scope for HTMX itself.

[benpate]

Hi Sirinath,

I think I misread your first note here. I had forgotten that ETags are already supported by browsers automatically, so there's nothing extra to do inside a framework like HTMX. I just tested a server update using ETag and If-None-Match headers, and everything worked great.

When I re-read your original note, I think you're saying that HTMX should skip the "swap" step if it recognizes that the content is coming from a cached value. Is this correct? If so, I have a counterexample of why this might not be a good idea.

What if I have two tabs, each loaded onto the page as a partial, and the content in each tab uses ETags. When I click back and forth between the two tabs, I need the page to change, even if the XHR request is returning a 304. Does this make sense?

In either case, I'm not sure this is something that could or should be changed.

[sirinath]

If data is not previously sent to the client send it and then send 304. If something changes the server will know and can send the updated data. If the value has not changed and fully rendered not need to swap. If it is not currently fully rendered then render it with cached values if possible.

[benpate]

I believe I follow you. So, HTMX would keep track of the URL currently displayed in every swappable area, and could use 304’s to skip rendering in these situations? That makes sense to me, but how often would this situation happen? Perhaps if you’re polling for changes on the site? How much work would this save on the browser by not swapping the data in at that point?

…

On Sat, Jul 25, 2020 at 1:51 AM, Suminda Sirinath Salpitikorala Dharmasena ***@***.***> wrote: If data is not previously sent to the client send it and then send 304. If something changes the server will know and can send the updated data. If the value has not changed and fully rendered not need to swap. If it is not currently fully rendered then render it with cached values if possible. — You are receiving this because you commented. Reply to this email directly, [view it on GitHub](#138 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABBNS4GA3F73ATHD5SHCOCLR5KFHDANCNFSM4OVRY5BA).

[sirinath]

HTMX just send the hash back to the server, the server keeps track and sends 304. HTMX just handles the 304 or new data. If it is 304 then there is no updates, else the swap is done.

[1cg]

We already had support for the 204 response code, adding the 304 response code was easy:

d5f6ef2

[makew0rld]

How can I get htmx to work with Last-Modified and If-Modified-Since headers, which are similar to etags but use time? Compliant servers will return 304 if the document hasn't been modified, and I assume htmx can handle that now, but will htmx send the Last-Modified header? And remember it and use it from past requests? Or am I misunderstanding and that's something the browser takes care of.

[benpate]

This should "just work" because the behavior is built in to your web browser. Your server will need to generate the appropriate caching headers, but then all browser AJAX requests (including those from htmx) will obey them.

If you're interested in caching, you might want to check out the preload extension (new in the latest release) which helps you to automatically load certain resources just before your users actually request them.

[makew0rld]

Ok, thanks!