Feedback on Availability Hints from Apple client perspective

Hi Mark,

Thanks for presenting the idea to improve Vary. I hope to provide some perspectives from our HTTP client cache implementation on Apple platforms.

1. URL is the key we use for cache, and we don’t save multiple variants of the same URL based on Vary. Our experience is that once a value in the request changes, it rarely changes back. E.g. people don’t usually change the device language back and forth; and once a cookie containing an auth token changes, the previous auth token won’t be valid again. So there is little point in keeping the previous variant around.

2. “Vary: Cookie” is common and often leads to valid responses to be thrown out. “Cookie-Indices” should improve cache hit rate.

3. “Vary: User-Agent” is another common cause of cache churn. Most browsers froze their user agent strings, but the default user agent string of our system HTTP client is something like “MyApp/1.0 CFNetwork/1470 Darwin/23.0.0”, so any time the app or the OS updates, the string would change. I understand that the servers want to retain the flexibility of serving different content per user agent to deploy new features or workaround bugs, but it is hard to model as Availability Hints.

Wondering if we can take a page out of dictionary compression and send the SHA256 of the current cached response, asking the server whether it needs to be updated.

Guoye Zhang

Received on Sunday, 30 July 2023 21:47:57 UTC