Re: Feedback on Availability Hints from Apple client perspective

> On Aug 1, 2023, at 22:03, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Hi Guoye,
> 
> Thanks for the feedback; responses below.
> 
>> On 31 Jul 2023, at 7:47 am, Guoye Zhang <guoye_zhang@apple.com> wrote:
>> 
>> 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.
> 
> Yes. As far as I'm aware, no major browser stores more than one variant at at time, currently (see: <https://cache-tests.fyi/#vary>, "An optimal HTTP cache can store two different variants").
> 
> However, that may change as features like Client Hints get traction, because they can change for a given browser. I know that some browsers are... lukewarm... about Client Hints, but that's OK -- the primary audience for Availability Hints is shared caches like those in CDNs.
> 
>> 2. “Vary: Cookie” is common and often leads to valid responses to be thrown out. “Cookie-Indices” should improve cache hit rate.
> 
> Yep. That design needs some iteration, though.
> 
>> 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.
> 
> Agreed. It may be best not to try to optimise this practice...
> 
>> 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.
> 
> From time to time I've wondered about something like an 'If-Hash' request header. I suspect that ETags are good enough, to the degree that there isn't enough benefit to justify a new thing.

Something along this line, have you considered flipping this hint the other way around? The client sends a list of variants it has currently cached, and the server can choose one of them or to send a new one.

GET /something
Accept-Language: en-AU
Accept-Encoding: gzip, br
Avail-Vary: Accept-Language=“en-US”, Accept-Encoding=“gzip”
Avail-Vary: Accept-Language=“en-GB”, Accept-Encoding=“gzip, br”

304
Avail-Vary: Accept-Language=“en-GB”, Accept-Encoding=“gzip, br”
Vary: Accept-Language, Accept-Encoding

Guoye
> 
> Later:
> 
>> We don’t currently put “If-None-Match: etag” on the new request if vary check failed, wondering if it’s safe to do so.
> 
> 
> See:
>  https://cache-tests.fyi/?id=conditional-etag-vary-headers-mismatch#
> (click on the test name to see a detailed description of what it's testing)
> 
> It looks like most caches don't try to do this, but Chrome and Firefox do, which implies that it works with the current Web. Presumably, both the upstream Vary check and INM check will fail, but that relies on the server sending the correct headers in every case, which of course they don't.
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

Received on Thursday, 3 August 2023 01:56:21 UTC