From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22789: 25.1.50; In last master build https connections stop working Date: Tue, 01 Mar 2016 05:35:13 +0200 Message-ID: <8360x698ge.fsf@gnu.org> References: <864mcyo14y.fsf@Lenovo-PC.i-did-not-set--mail-host-address--so-tickle-me> <87d1rmxl65.fsf@gnus.org> <86povm6qeu.wl-j_l_domenech@yahoo.com> <83k2lugeym.fsf@gnu.org> <871t81wtyt.fsf@gnus.org> <87r3g1veqc.fsf@gnus.org> <86si0euizj.fsf@realize.ch> <871t7xhj7t.fsf@gnus.org> <86oab1vjm9.fsf@realize.ch> <86d1rhpvcq.fsf@realize.ch> <834mctbitq.fsf@gnu.org> <868u25p3m2.fsf@realize.ch> <83io18ahya.fsf@gnu.org> <86y4a3on6f.fsf@realize.ch> <87oaazg7fv.fsf@gnus.org> <86twkro0vr.fsf@realize.ch> <83d1rf8ifj.fsf@gnu.org> <87io17gqjo.fsf@gnus.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1456803385 11975 80.91.229.3 (1 Mar 2016 03:36:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Mar 2016 03:36:25 +0000 (UTC) Cc: j_l_domenech@yahoo.com, a.s@realize.ch, 22789@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 01 04:36:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aab6a-0004EV-RN for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Mar 2016 04:36:13 +0100 Original-Received: from localhost ([::1]:40581 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aab6a-0000es-2W for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Feb 2016 22:36:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aab6U-0000do-Ch for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 22:36:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aab6Q-00069D-Av for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 22:36:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aab6Q-000693-6X for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 22:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aab6Q-0004iF-0U for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 22:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Mar 2016 03:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22789-submit@debbugs.gnu.org id=B22789.145680334218083 (code B ref 22789); Tue, 01 Mar 2016 03:36:01 +0000 Original-Received: (at 22789) by debbugs.gnu.org; 1 Mar 2016 03:35:42 +0000 Original-Received: from localhost ([127.0.0.1]:54522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aab63-0004hY-94 for submit@debbugs.gnu.org; Mon, 29 Feb 2016 22:35:42 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44959) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aab5y-0004hJ-EJ for 22789@debbugs.gnu.org; Mon, 29 Feb 2016 22:35:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aab5p-00065g-8X for 22789@debbugs.gnu.org; Mon, 29 Feb 2016 22:35:29 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48385) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aab5p-00065c-5E; Mon, 29 Feb 2016 22:35:25 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aab5o-0002ul-BW; Mon, 29 Feb 2016 22:35:24 -0500 In-reply-to: <87io17gqjo.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 01 Mar 2016 08:22:35 +1100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114208 Archived-At: > From: Lars Ingebrigtsen > Cc: Alain Schneble , j_l_domenech@yahoo.com, 22789@debbugs.gnu.org > Date: Tue, 01 Mar 2016 08:22:35 +1100 > > Eli Zaretskii writes: > > > I already tried increasing the limit, it doesn't help: the new limit > > is reached. Interestingly, when the initial connection is made, for > > the page itself, the handshake completes within 10 attempts. But the > > subsequent connections, presumably for images, don't succeed, for some > > reason. > > For the images, it tried handshaking 100 times and then marked the > connections as failed? It tried as many times as I gave it (I even tried 1000), yes. I didn't check that it marks the connection as failed, but that's deterministic, no? > > Failing that, I came to a conclusion that I don't have a clear and > > complete picture of what should happen when eww receives the page and > > proceeds to downloading the images. Lars, can you please describe > > what eww does at this point, and how these downloads are expected to > > work asynchronously? You can describe what happens on GNU/Linux, if > > that makes it easier. In particular, what are the differences between > > the initial connection to get the page (which works) and the > > connections made to get the images (which don't work)? > > As I said before, the images are fetched from `url-queue', which gives > up if the image hasn't downloaded within five seconds. Could that be > the case for you? Unlikely: I tried enlarging the limit to 120 sec, and the problem wasn't fixed. I feel that we don't really understand the problem, so we are trying random things "just because they are there". I think we should try to understand what's not working first. > > There is also some disturbing signs in retrying GnuTLS handshake from > > wait_reading_process_output -- I'm not sure the way that function > > works, at least on Windows, is according to you expectations. The > > while loop there doesn't really spin all the time, did you know that? > > It runs every time something is available from poll, doesn't it? Which > is what we care about. I think. But something might not become available from the poll for prolonged periods of time. Why would we rely on the loop there to crank frequently enough for the purposes of completing the TLS handshake? E.g., does it work well for you if you disable cursor blinking before invoking eww?