Sketch interaction with caching intermediaries

[twifkak]

In addition to helping proactive content negotiation in the endpoint server, it seems like this would help caching intermediaries:

• compute a cache key
• prewarm all variants in the cache, based on a list of variants received from the endpoint

Is this a goal, a non-goal (nice side effect that may break), or an anti-goal (non-desired side effect)?

If a goal, it would be nice to sketch out how this could be achieved, for example by appending to Appendix A of Variants.

[miketaylr]

Is this a goal, a non-goal (nice side effect that may break), or an anti-goal (non-desired side effect)?

I think @yoavweiss will have more intelligent thoughts to this issue than me... 😅

[yoavweiss]

The fact that the different content negotiation dimensions are broken up into separate headers which can be Varyied on was definitely a goal in the design, and is mentioned in the RFC.

I'm not sure what flow you have in mind regarding cache pre-warming though. It seems like you'd need to gather "intelligence" for a while on the server before have some certainty that you have all the variants, right? Is that materially different than simply caching the variants as they come? Or are you thinking of applying variants from one resource onto other resources?

[twifkak]

Prewarming is secondary (to me) to the cache key, but AFAICT the Variants spec designs for both use cases. The endpoint server specifies a list of variants it serves (both key and value). No longitudinal intelligence-gathering necessary.

To integrate a header with Variant-Key / Variants from that spec, it appears two things are necessary:

• Define the available-value grammar (i.e. the cache key).
• Define how intermediaries content-negotiate from a request header field value to one of a list of available-values.

In both cases, this seems pretty simple, but worth defining explicitly. (Especially the latter, given that UA is a GREASEd set.)

[twifkak]

I should add: I don't mean to advocate for Variants in particular (at least not in this thread). But I think it's a useful reference, as the "two things" necessary for Variants would also be useful for a caching scheme based on Vary.