My preference would be not to cache the policy by the reverse-proxy. Like Dan said, the provider can handle more traffic than the proxy, hence I think caching is not a requirement. Provider may set appropriate Cache-Control HTTP header to prevent caching Example:Cache-Control: no-cache, no-store, must-revalidate
If caching is desired, then provider may set a Cache-Control policy with an short TTL. The proxy may cache the policy until the cache expires. Thanks,-binu https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control From: Viktor Dukhovni <[email protected]> To: [email protected] Sent: Monday, 2 October 2017 1:43 PM Subject: Re: [Uta] Updated MTA-STS & TLSRPT On Sat, Sep 30, 2017 at 11:15:45AM +0200, Daniel Margolis wrote: > Regarding caching, Viktor, Binu, do you believe this is useful to allow? I think it is useful. > While it can be done safely (by simply ensuring the cache-control headers > set by the mta-sts.provider.com host--i.e. the one behind the proxy--are > "correct"), it doesn't strike me as necessary; perhaps it's simpler and > safer to simply recommend against HTTP caching. The expected request rate > is low, and I would assume any provider behind the proxy can handle more > traffic than the proxy itself, so caching isn't quite as compelling, no? The provider can likely handle the query rate just fine, but serving cached content is much cheaper than making upstream connections to the provider. So I think this is attractive for the site doing the delegation. -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
