When loading Web access (and also tlwebadm?) in Internet Explorer it usually stalls the first time for 30 seconds before the page finishes loading. It seems to work fine after that. I can see the following in the log: > 2019-10-08 15:12:14 INFO tlwebaccess[46343]: [::ffff:10.48.0.102] 'GET / HTTP/1.1' 301 - > 2019-10-08 15:12:44 ERROR tlwebaccess[46343]: [::ffff:10.48.0.102] Request timed out: timeout('client exceeded maximum timeout',) > 2019-10-08 15:12:44 INFO tlwebaccess[46353]: [::ffff:10.48.0.102] 'GET /main/ HTTP/1.1' 200 - Is this some fallout from bug 7187? It seems to work fine for other browsers though.
Also see bug 6162 which is also about issues loading files.
The stall happens during TLS shutdown, but oddly enough only for the redirect from / to /main/, not for anything else. What we can see is that we call gnutls_bye() which seems to send a CloseNotify to the browser. GnuTLS then flags that it wants more data and we select() waiting for that data. However no such data ever shows up. Comparing with a working request we can see gnutls_bye() getting called as well, with something being sent (again likely CloseNotify). However no data is received in that case either. Instead IE closes the TCP socket.
Adding a Content-Length: 0 makes everything work. It seems IE doesn't like using a TLS close as a way of indicating that a response is fully sent. We don't want to change tlstunnel to stop doing the closure, so let's add the content length header to our redirects.
We implemented and tested this together, so nothing more to test.
Not sure we've fully solved this. We're still seeing this on the initial use of tlwebadm both with IE and Edge. The network tool shows that both the 401 and 302 takes ~30 seconds to complete.
We had indeed overlooked the 401 response. Works better now.
Tested tlwebadm on IE and Edge 18 for Windows 10 and it works fine without any delay in loading times. Also tested IE on Windows 7 and it works there as well.
