Bug 7392 - page loading sometimes stalls with internet explorer
: page loading sometimes stalls with internet explorer
: ThinLinc
Web Access
: trunk
: PC Unknown
: P2 Normal
: 4.11.0
Assigned To:
  Show dependency treegraph
Reported: 2019-10-08 15:17 by
Modified: 2019-12-02 14:13 (History)
Acceptance Criteria:



You need to log in before you can comment on or make changes to this bug.

Description From cendio 2019-10-08 15:17:45
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:] 'GET / HTTP/1.1' 301 -
> 2019-10-08 15:12:44 ERROR tlwebaccess[46343]: [::ffff:] Request timed out: timeout('client exceeded maximum timeout',)
> 2019-10-08 15:12:44 INFO tlwebaccess[46353]: [::ffff:] 'GET /main/ HTTP/1.1' 200 -

Is this some fallout from bug 7187?

It seems to work fine for other browsers though.
------- Comment #1 From cendio 2019-10-10 10:09:28 -------
Also see bug 6162 which is also about issues loading files.
------- Comment #2 From cendio 2019-11-07 09:56:36 -------
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.
------- Comment #3 From cendio 2019-11-07 10:43:19 -------
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.
------- Comment #5 From cendio 2019-11-07 10:49:13 -------
We implemented and tested this together, so nothing more to test.
------- Comment #7 From cendio 2019-12-02 10:28:30 -------
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.
------- Comment #9 From cendio 2019-12-02 10:48:20 -------
We had indeed overlooked the 401 response. Works better now.
------- Comment #10 From cendio 2019-12-02 14:13:46 -------
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.