- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 25 Apr 2014 14:29:31 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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