From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: url-retrieve-synchronously randomly fails on https URLs (patch included) Date: Sat, 27 Oct 2007 19:41:39 -0400 Message-ID: References: <20071027104716.E9BA773545@tanja.localdomain> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1193528599 26404 80.91.229.12 (27 Oct 2007 23:43:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Oct 2007 23:43:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: riccardo.murri@gmail.com (Riccardo Murri) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 28 01:43:20 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IlvJH-0005JU-RR for ged-emacs-devel@m.gmane.org; Sun, 28 Oct 2007 01:43:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IlvJ9-0000sK-1X for ged-emacs-devel@m.gmane.org; Sat, 27 Oct 2007 19:43:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IlvHg-0007oR-Ks for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:41:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IlvHf-0007nL-UB for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:41:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IlvHf-0007n1-ON for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:41:39 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IlvHf-0001xL-LC for emacs-devel@gnu.org; Sat, 27 Oct 2007 19:41:39 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1IlvHf-0006Wd-1j; Sat, 27 Oct 2007 19:41:39 -0400 In-reply-to: <20071027104716.E9BA773545@tanja.localdomain> (riccardo.murri@gmail.com) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:81897 Archived-At: I traced down the bug to `open-tls-stream', which returns immediately after having seen the regexp `tls-success' in the buffer. However, both `openssl s_client' and `gnutls' print more information after that line, thus `open-tls-stream' may occasionally return the buffer to the caller when point is still amidst openssl/gnutls output. A solution is to have `open-tls-stream' wait a little more to accept output; after applying the patch below I cannot trigger the error anymore. + (if (not done) + (delete-process process) + ;; both `openssl s_client' and `gnutls' print some more info + ;; after the line matched by regexp `tls-success'; wait here + ;; a bit more, so we can be sure that point is at the end of + ;; it all, before handing the buffer back to caller + (accept-process-output process 1) + (setq done process)))) This is not totally reliable, because it is possible for accept-process-output to get just part of the output. That may be unlikely, which is why you have not seen it happen, but it is possible. So here is another suggestion. Can you change the `tls-success' regexp so that it matches all the text that openssl or gnutls would produce? (You might need to use \(...\|...\) to match each on separately.)