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: Sun, 28 Feb 2016 19:00:13 +0200 Message-ID: <83io18ahya.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1456678913 17553 80.91.229.3 (28 Feb 2016 17:01:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Feb 2016 17:01:53 +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 Sun Feb 28 18:01:41 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 1aa4iy-0004y1-4k for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Feb 2016 18:01:40 +0100 Original-Received: from localhost ([::1]:59795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa4ix-00076e-28 for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Feb 2016 12:01:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa4iP-00068A-OV for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 12:01:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aa4iM-0002mB-Hz for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 12:01:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa4iM-0002m7-FR for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 12:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aa4iM-0001Ap-9T for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2016 12:01: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: Sun, 28 Feb 2016 17:01: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.14566788404474 (code B ref 22789); Sun, 28 Feb 2016 17:01:02 +0000 Original-Received: (at 22789) by debbugs.gnu.org; 28 Feb 2016 17:00:40 +0000 Original-Received: from localhost ([127.0.0.1]:50941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aa4i0-0001A6-Cp for submit@debbugs.gnu.org; Sun, 28 Feb 2016 12:00:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:37973) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aa4hz-00019s-1l for 22789@debbugs.gnu.org; Sun, 28 Feb 2016 12:00:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aa4hq-0002cp-AJ for 22789@debbugs.gnu.org; Sun, 28 Feb 2016 12:00:33 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aa4hq-0002ce-7z; Sun, 28 Feb 2016 12:00:30 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3445 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aa4ho-0005Zk-JJ; Sun, 28 Feb 2016 12:00:29 -0500 In-reply-to: <868u25p3m2.fsf@realize.ch> (message from Alain Schneble on Sun, 28 Feb 2016 10:48:37 +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:114048 Archived-At: > From: Alain Schneble > CC: , , <22789@debbugs.gnu.org> > Date: Sun, 28 Feb 2016 10:48:37 +0100 > > If I swap the order of the if statements in sys_write to look as > follows, then the reason for the SOCKET_ERROR is revealed: > > if (nchars == SOCKET_ERROR) > { > DebPrint (("sys_write.send failed with error %d on socket %ld\n", > pfn_WSAGetLastError (), SOCK_HANDLE (fd))); > set_errno (); > } > > /* Set the socket back to non-blocking if it was before, > for other operations that support it. */ > if (fd_info[fd].flags & FILE_NDELAY) > { > printf ("reset file_ndelay"); > nblock = 1; > pfn_ioctlsocket (SOCK_HANDLE (fd), FIONBIO, &nblock); > } > > => WSAENOTCONN (10057): Socket is not connected. So that's the prove it > accesses the socket too early. Yes. > Alas, even though it seems to help at least for the test code I tried, > turning WSAENOTCONN into EAGAIN seems wrong after all. It does here, although this needs to be done only if the socket is in the process of connecting, and the return value needs to be negative, not zero. I installed a fix along these lines, and it seems to work for me: https://www.fsf.org is displayed OK. > It shouldn't try to write to the socket before it is connected at > all...(?) No, I think it should: that write comes from GnuTLS, when it attempts a handshake. Returning EWOULDBLOCK tells GnuTLS to spin waiting until the connection is complete. How else could this work, since we now proceed with GnuTLS handshake immediately after the call to 'connect' returns, when the connection is not yet complete, this being a non-blocking socket? > Also the code "wraps" pfn_send and turns it into a blocking call. > Not sure what the implications are... The only implication is that we get ENOTCONN instead of EWOULDBLOCK. But that's easy to handle. > Nevertheless, don't you think the error handling in this code section is > not very elaborate and switching the order as shown above might be > better anyway? sys_write is primarily about writing, not about > switching from non-blocking to blocking and back again... Or shall it > somehow aggregate possible errors of both calls (pfn_send and > pfn_ioctlsocket)? Yes, you are right. I did that. The only problem left is that not all images on www.fsf.org's page are downloaded; they are if I use http instead of https. I guess this is some eww thing?