A lot of our clients use proxies, and they sometimes have terrible bugs that cause connection problems. E.g. the other day we detected an obsolete Cisco device that was leaking memory from one HTTPS session into another (a government department too!).
We now log whether HTTP2 or HTTP1.1 is used by the browser by using JavaScript: `window.performance.getEntries()[0].nextHopProtocol` which is supported by most modern browsers.
This works because we use CloudFlare, so most of our users get HTTP2, unless they are using a corporate proxiy, which often downgrade the browser connection to HTTP1.1. e.g. Cisco WSA doesn't support HTTP/2 yet[1].
We also log response headers on XMLHTTPRequests that fail, because sometimes the proxy inserts a header with its name and version (however headers sometimes get stripped for security reasons by the browser e.g. CORS, and timeouts usually have no response header).
One other handy tool can be https://badssl.com/dashboard/ for doing a quick scan for surprises — this is especially useful if you're testing managed workstations and want to confirm that someone hasn't “fixed” a problem by deploying a group-policy update which breaks TLS security.
We now log whether HTTP2 or HTTP1.1 is used by the browser by using JavaScript: `window.performance.getEntries()[0].nextHopProtocol` which is supported by most modern browsers.
This works because we use CloudFlare, so most of our users get HTTP2, unless they are using a corporate proxiy, which often downgrade the browser connection to HTTP1.1. e.g. Cisco WSA doesn't support HTTP/2 yet[1].
We also log response headers on XMLHTTPRequests that fail, because sometimes the proxy inserts a header with its name and version (however headers sometimes get stripped for security reasons by the browser e.g. CORS, and timeouts usually have no response header).
1. https://quickview.cloudapps.cisco.com/quickview/bug/CSCuv329...