W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #444: Flushing Alt-Svc Cache

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 25 Apr 2014 14:29:31 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1AC6E831-F2B3-4E2B-BDDD-88A7DCC0AD48@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>
Agreed; we could mention that with a MAY...


On 25 Apr 2014, at 2:26 pm, Martin Thomson <martin.thomson@gmail.com> wrote:

> I think that's workable.  The cost is that certain classes of device
> will perform discovery a lot.  Those devices could maintain
> per-network caches for alt-svc, I suppose.
> 
> For example, my phone goes from home, to a mobile network, to the
> office quite often, it would be nice if alt-svc for my home were able
> to be reused when I return in the evening, subject to the TTL, of
> course.
> 
> On 24 April 2014 17:34, Mark Nottingham <mnot@mnot.net> wrote:
>> <https://github.com/http2/http2-spec/issues/444>
>> 
>>> For the load balancing use case, it's necessary for clients to always flush altsvc cache upon a network change, but right now they're only required to examine the cache for suspicious entries. We should discuss whether this should be upgraded to always flush.
>> 
>> I think the logical proposal would be to change <http://http2.github.io/http2-spec/alt-svc.html#caching>
>> 
>> """
>> To mitigate risks associated with caching compromised values (see Section 7.2 for details), user agents should examine cached alternative services when they detect a change in network configuration, and remove any that could be compromised (for example, those whose association with the trust root is questionable). UAs that do not have a means of detecting network changes should place an upper bound on their lifetime.
>> """
>> 
>> to read:
>> 
>> """
>> To mitigate risks associated with caching compromised values (see Section 7.2 for details), user agents should remove all cached alternative services when they detect a change in network configuration. UAs that do not have a means of detecting network changes should place an upper bound on their lifetime.
>> """
>> 
>> Thoughts?
>> 
>> 
>> Cheers,
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 25 April 2014 04:28:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC