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: Mon, 29 Feb 2016 20:45:04 +0200 Message-ID: <83d1rf8ifj.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1456772601 1423 80.91.229.3 (29 Feb 2016 19:03:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 19:03:21 +0000 (UTC) Cc: larsi@gnus.org, j_l_domenech@yahoo.com, 22789@debbugs.gnu.org To: Alain Schneble Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 29 20:03:02 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 1aaT5x-0007tk-4w for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Feb 2016 20:03:01 +0100 Original-Received: from localhost ([::1]:38584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaT5w-0005NU-CU for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Feb 2016 14:03:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaSpa-0002dK-Cu for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 13:46:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaSpW-0000iZ-Hz for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 13:46:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaSpW-0000iV-F6 for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 13:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aaSpW-0003Ib-A7 for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 13:46: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: Mon, 29 Feb 2016 18:46:02 +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.145677153712649 (code B ref 22789); Mon, 29 Feb 2016 18:46:02 +0000 Original-Received: (at 22789) by debbugs.gnu.org; 29 Feb 2016 18:45:37 +0000 Original-Received: from localhost ([127.0.0.1]:54013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaSp4-0003Hr-70 for submit@debbugs.gnu.org; Mon, 29 Feb 2016 13:45:37 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41768) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaSoz-0003Hb-5S for 22789@debbugs.gnu.org; Mon, 29 Feb 2016 13:45:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaSop-0000aF-Qi for 22789@debbugs.gnu.org; Mon, 29 Feb 2016 13:45:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaSop-0000aB-OR; Mon, 29 Feb 2016 13:45:19 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4990 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aaSon-0007dj-Dr; Mon, 29 Feb 2016 13:45:18 -0500 In-reply-to: <86twkro0vr.fsf@realize.ch> (message from Alain Schneble on Mon, 29 Feb 2016 18:57:28 +0100) 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:114158 Archived-At: > From: Alain Schneble > Date: Mon, 29 Feb 2016 18:57:28 +0100 > Cc: j_l_domenech@yahoo.com, 22789@debbugs.gnu.org > > Lars Ingebrigtsen writes: > > > Alain Schneble writes: > > > >> What I had in mind was to start the GnuTLS handshake (or even > >> gnutls_boot) only after the async socket has properly been connected. I > >> just consulted the GnuTLS documentation and I understand now that what > >> you write above is indeed a supported GnuTLS scenario. But I think it > >> is not an optimal one, because the number of TLS handshake retries will > >> then depend on the time it takes to setup the socket connection, IIUC > >> (see process.c: abort if p->gnutls_handshakes_tried > > >> GNUTLS_EMACS_HANDSHAKES_LIMIT). > > > > We could just increase that limit. It's currently set to 100, which is > > a number that's taken from thin air, I think? It should probably be a > > time-based handshake limit instead -- try handshaking for, say, ten > > seconds before giving up... > > A time-based limit sounds like a good idea to me. It could even be > combined with a min-number-of-tries approach, like this: > > if (TimeElapsed > Timeout && NumberOfTries > MinNumberOfTries) { > // give up... > } 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. > But the point I tried to address is the following: /When/ shall we start > with the handshake "series" and start counting the number of tries (or > stopwatch)? Don't you agree that with async sockets, it doesn't make > much sense to start it before the socket is connected? So we could just > postpone it until then... Otherwise, the number of handshake tries (or > time elapsed) durnig the "socket not yet connected" are subtracted from > the max number of tries (or timeout) granted. Which I think is, well, > at least imprecise... I think we are looking in the wrong direction. We need first to understand why the connection(s) to download the images don't work. Does anyone already have an idea why this happens? If so, please describe that. 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)? 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? Can you describe what you think should happen there for a connection whose GnuTLS handshake is not yet complete?