Users accessing internal Web application via ZTNA service.
After logging in and accessing the resource, the application login page should be rendered prompting users for credentials but a blank page is rendered instead.
Problem appears with Chrome but not with Firefox.
HAR file shows requests for all CSS/JS objects on the login page.
Accessing the application directly shows the login page correctly.
ZTNA web application.
Problems with the encoding of the returned objects needed for login page display.
Use link translation rules to force the response data to be encoded using GZIP or DEFLATE, and not the BR encoding type that caused the issue as shown below:
The HAR files from Chrome and Firefox showed requests for the same login page objects with 200 OK. The main difference was that the payload of the 200 OK response when it failed was blank for certain JS/CSS objects.
Looking at the content-encoding HTTP response header, we could see the BR (format using the Brotli algorithm) type returned when it failed, versus GZIP when it worked. Since this response header is linked to the advertised 'Accept-encoding' HTTP request header algorithms, the ZTNA admin rewrote this accept-encoding header to remove the BR format and all worked fine.
Note that other sites worked with Chrome using this BR encoding, so it was specific to this web server implementation.