Bug 7392 - page loading sometimes stalls with internet explorer
Summary: page loading sometimes stalls with internet explorer
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.11.0
Assignee: Pierre Ossman
Keywords: relnotes
Depends on:
Reported: 2019-10-08 15:17 CEST by Pierre Ossman
Modified: 2019-12-02 14:13 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2019-10-08 15:17:45 CEST
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 Pierre Ossman cendio 2019-10-10 10:09:28 CEST
Also see bug 6162 which is also about issues loading files.
Comment 2 Pierre Ossman cendio 2019-11-07 09:56:36 CET
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 Pierre Ossman cendio 2019-11-07 10:43:19 CET
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 Pierre Ossman cendio 2019-11-07 10:49:13 CET
We implemented and tested this together, so nothing more to test.
Comment 7 Pierre Ossman cendio 2019-12-02 10:28:30 CET
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 Pierre Ossman cendio 2019-12-02 10:48:20 CET
We had indeed overlooked the 401 response. Works better now.
Comment 10 Alex Tanskanen cendio 2019-12-02 14:13:46 CET
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.

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