Suppose the following sequence of events happen:
1) Chrome sends a request for an image resource to the currently configured DRP.
2) Chrome updates the DRP proxy config, causing a new and different list of proxies to be used for the DRP.
3) The response for that image comes back from the previously-configured DRP.
4) Since DataReductionProxyConfig::IsDataReductionProxy() only checks the proxy_server against the currently configured DRP targets, which doesn't include that old DRP target, Chrome doesn't treat that image response as having come from the DRP.
The exception to this is that most of the DRP bypass logic would still apply, since there's currently a hack in the bypass logic to treat any response with the DRP Via header from any proxy as if it was from a DRP proxy. This happens a tiny but non-zero number of times, see the DataReductionProxy.ResponseProxyServerStatus histogram.
I'm removing this hack, though, so we should actually solve this problem, such as by having the DataReductionProxyConfig keep track of the last N lists of configured DRP targets, and treat any proxy that matches a proxy on those lists as a DRP.
N = 1 will probably be enough.
Comment 1 by bugdroid1@chromium.org
, May 8 2018