[jwrosewell]

Not a fix for #12, and not for release. Run against the two remote hosts over HTTPS with this commit, both browser cache tests and both client-side override tests still failed on both hosts, so a compressed answer is not what stops the page defining fod. The details are under "How it was checked". Kept as a draft until the cause is found, because asking for identity may still belong in the eventual fix.

The problem

TestHelpers.ProxyingListener serves a test page from http://localhost:<port>/ and relays /api/ requests to the cloud under test. HttpServer.ProxyTo forwarded every browser header, Accept-Encoding included, and copied the cloud's answer back with its Content-Encoding unchanged. A cloud reached over HTTPS answers Content-Encoding: br to a browser's gzip, deflate, br, zstd, and over plain HTTP the same cloud answers gzip. Relayed to the page, the gzip answer works and the Brotli answer leaves fod undefined, so JavaScript_BrowserCache_Chrome and JavaScript_BrowserCache_FireFox fail against any cloud reached over HTTPS, as #12 sets out.

Checked again on 14 November 2026 against two remote hosts. Both browser cache tests failed over HTTPS on both hosts with scriptLoaded=True, fodDefined=False, and passed on both hosts over plain HTTP. The hosts answered Content-Encoding: br over HTTPS and gzip over HTTP.

The change

The relay no longer forwards the browser's Accept-Encoding, and sends Accept-Encoding: identity instead, so the cloud answers uncompressed and the bytes copied back are plain whatever the cloud would otherwise choose. Leaving the header out would not be enough, because RFC 9110 section 12.5.3 says "If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent". The same section defines "identity" as a synonym for no encoding. Asked with identity, both hosts answered with no Content-Encoding.

Every relay in HttpServer goes through ProxyTo, so the example relays get uncompressed answers too. No test in the suite checks the encoding of a relayed answer.

How it was checked

• The suite's own checks on this pull request build the change.
• Against the two remote hosts over HTTPS with this commit (9f172fc), the cloud-internal group gave 31 passed, 4 failed and 14 skipped on each host. The four failures were JavaScript_BrowserCache_Chrome, JavaScript_BrowserCache_FireFox and both JavaScript_ClientSideOverrides cases, the same four as without the change.
• The client-side override tests, changed for that run only to print the page's state on a timeout, showed the script request answered 200 through the relay and fod undefined, with one console error, Uncaught ReferenceError: fod is not defined, from the page's own window.onload. The same with six different resource keys.
• The script itself is sound. Fetched from the same host by curl, over HTTP and over HTTPS, with the relay's Host: localhost:<port>, it is about 55 KB and ends var fod=new fiftyoneDegreesManager. Served from a local web server, both versions define fod in headless Chrome with no error. So the fault lies in what the browser receives through the relay from a remote cloud, which is not yet established.