Could we just remove the LOAD_DISABLE_CACHE for proxy fetching, and call it a day?  Speaking of which...Should we also disable cookies (And auth?) when fetching PAC scripts?

I don't think dropping LOAD_DISABLE_CACHE alone is a good solution:

  * We want to bypass the cache when re-fetching PAC in response to a network change (since the same URL may be served by a totally different server on the new network).

  * We still need a way to check for changes to the file and re-initialize once detected. If we kept the current ad-hoc polling policy, but then had the URLRequest itself go through the cache, we could still use stale cache. Also the polling mechanism stalls ProxyService.

So it wouldn't just be a one line change.

Regarding cookies and auth, that probably requires some more compatibility investigation. I'll file something for that.

For your first case, we could just force a reload on connection change (And on the initial request).

Your second point confuses me.  Obeying caching directives and checking for changes ignoring the caching directive are two direct opposite goals.  It's impossible to do both at once.  If we respect caching directives, that's logically equivalent to doing a normal fetch, using the cache.  If we're concerned about using the cache causing problems, that's logically equivalent to always bypassing the cache and ignoring caching directives, as we do now.

There seems to be a disconnect here.

The PAC script is not requested for each proxy resolution. If it were, then one could simply do a normal fetch respecting caching headers each time and resolve this (along with some logic to flush the cache on network changes).

That is now how the system works though. The PAC script is currently fetched at pre-set intervals (the polling mechanism). This proposal is to align those polling intervals with expected TTLs from the cache headers, rather than arbitrary times.

Right, but if we just reloaded every, say, 30 minutes, allowing a response from the cache, but don't use the caching headers directly, we'd basically accomplish the same thing (Modulo very short lived PAC scripts).

My concern is mostly around dealing consistently with cache headers, in terms of complexity, correctness, and dealing with new directives (Like the new cache-control: immutable directive)

Reloading every 30 minutes is likely a bad idea.

We have had issues in the past where changes to polling frequency brought down PAC servers, and consequently broke users connectivity. In fact we even experienced that internally.

If we went that route, we would also need to re-design these reloads to not block, since otherwise we may re-jank at regular intervals.

So if the response is valid (Without revalidation) for more than 30 minutes, we wouldn't be hitting the server again.  If it's not...wouldn't paying attention to the re-validation headers result in trying every 30 minutes (Or less), anyways?