search

WICG / compression-dictionary-transport

Other
92 stars 8 forks source link

Use case for TTL decoupled from cache freshness #57

Closed yoavweiss closed 3 months ago

yoavweiss commented 4 months ago

For the case of dynamic HTML resources, I can see sites with low number of returning visitors, where it can be beneficial to e.g. reuse the HTML delivered as part of the current page for future versions of the same page or for similar pages (e.g. reuse the HTML from one product page to another).

But very often, such HTML pages (especially with publishers and e-commerce) are served with very low caching freshness lifetime (if any), to ensure that typos or page errors won't live on in the browser's cache.

At the same it'd be great to be able to use these pages as a dictionary for a long while.

So it'd be great to be able to define both Cache-Control max-age and a dictionary TTL, have the browser cache keep the resource around for the duration of the longest amongst the two, but only use it for the case for which it is still fresh.

pmeenan commented 4 months ago

As it stands right now, navigation resources (i.e. the HTML) aren't allowed to be used as dictionaries (and are likely to have private data).

pmeenan commented 3 months ago

Previous discussion on the topic: https://github.com/WICG/compression-dictionary-transport/issues/50

It's possible that it's safe to use but it's more complicated than subresources so isn't currently supported (at least in Chrome).

yoavweiss commented 3 months ago

Looking at https://github.com/WICG/compression-dictionary-transport/issues/50 I'm not convinced that we shouldn't be using navigation resources as same-origin dictionaries from a security perspective (as they are readable by the site that would use them).

At the same time, talking to @pmeenan, he convinced me that reusing dynamic resources as dictionaries is not practical on the server, as it'd create a huge number of dictionaries to keep around, and won't be amenable to offline compression. So closing..