Your net-log shows four attempts to fetch the PAC script. Three requests get HSTS redirected to HTTPS and PAC script server refuses connection on the SSL port 443.  One request does not get HSTS redirected and successfully downloads PAC script from HTTP port 80.

Things that seem odd:
1. Only some requests are HSTS redirected, but not all requests.  I don't see any HSTS headers going by so I don't know why this state changes.
2. I don't see "pac.mycompany.com" in the HSTS preload list so I'm not sure why it's getting HSTS redirected at all.

Ryan, any idea why a request for the PAC script from pac.mycompany.com would get HSTS redirected, and only some of the time?

Perhaps related to Issue 794674?

As to why it would get HSTS redirected in any scenario, the most likely explanation based on the behavior described is that a prior visit to "https://mycompany.com" resulted in a response with a Strict-Transport-Security header with an includeSubdomainsDirective.

Please visit this URL:

   chrome://net-internals/#hsts

and type pac.mycompany.com in the box under Query HSTS/PKP domain and run the query.

Respecting HSTS on the domain serving the PAC script (At least for requests not using the SystemURLRequestContext) is also a side effect of the CL that caused issue 794674.

Now that the NetworkService sets up proxy configuration, we could switch back to using a separate global in-memory URLRequestContext to make proxy requests, but I'm not convinced we should.  We'd still probably need an API to configure it, so it's not using different settings than other URLRequestContexts, and it increases memory overhead.

I can't see Issue 794674.

The weird thing is the requests alternated getting HSTS redirected, i.e. one got redirected, then one did not get redirected, then one got redirected.  I didn't see any HSTS headers going by in the interim.

HSTS is per-URLRequestContext.  If some URLRequestContexts have seen an HSTS header for the domain, and some have not, they'll see different behaviors.  They won't see each other's PAC scripts, so requests on one should always hang (Until the HSTS entry times out), while requests to the other will all work (Unless HSTS is later set on the domain in that URLREquestContext, in which case, it will start failing, too).

Thanks for the report!

I agree with comments #3, and #4:
 (a) This is a behavior change from  issue 715697 , which launched in (M60)
 (b) HSTS was probably previously set on https://mycompany.com/ with includeSubdomainsDirective
 (c) Ergo it is not incorrect for pac.mycompany.com to require HTTPS (and subsequently fail because it is being filtered).

I am closing this as WontFix on the basis that the HSTS situation for that server needs to be fixed to not includeSubdomainsDirective (or use a different host for the PAC script).

There shouldn't be an expectation that PAC requests use an isolated HSTS store.

PAC is already catastrophically unspecified, and we have no end of hacks. For comparison, Chrome's treatment of HTTP cache, cookies, HTTP auth, certificate revocation checks, connection pooling, etc, are also basically arbitrary implementation choices when it comes to PAC.

Could you confirm if Chrome attempts to download the PAC file every time it is opened? Or does it cache the PAC file for a set period of time? 

I have checked mycompany.com in chrome://net-internals/#hsts and it does indeed show mycompany.com as a dynamic STS domain with include_subdomains set to true.

However I would have thought I could now recreate this fault on demand by visiting https://mycompany.com and then opening a new window, however I have not been able to do this, after visiting https://mycompany.com I can still use Chrome to browse the internet without this fault occuring.

We always bypass the HTTP cache when fetching PAC scripts.  We don't re-download the PAC script for every HTTP[S] request once Chrome is started, of course, since that would destroy performance, though we do periodically fetch it again.

I'm not familiar with the HSTS code.  It may be that we don't block network requests on loading HSTS information from disk (i.e., it may be possible that the network request is being sent before HSTS data is loaded).

Go to chrome://net-internals/#proxy and click the "Re-apply settings" button.
This will cause Chrome to re-fetch the PAC file, if you need to test things.

The exact time when PAC is fetched, and when it is refreshed for changes, may otherwise appear arbitrary, as there are a complicated set of polices around it.