Should open-tls-stream signal an error?

Should open-tls-stream signal an error?

[Magnus Henoch]

open-tls-stream in tls.el returns nil on failure (gnutls-cli binary
not found, connection refused, etc).  open-network-stream signals an
error when it can't connect.  Is there any reason open-tls-stream
shouldn't do the same, instead of just returning nil?

Magnus

Re: Should open-tls-stream signal an error?

[Carl Henrik Lunde]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

A long time ago Magnus Henoch <mange@freemail.hu> wrote:

> open-tls-stream in tls.el returns nil on failure (gnutls-cli binary
> not found, connection refused, etc).  open-network-stream signals an
> error when it can't connect.  Is there any reason open-tls-stream
> shouldn't do the same, instead of just returning nil?

As nobody answered Magnus I made a patch, it seems to work like
open-network-stream on errors, but it's hardly tested.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Make open-tls-stream behave like open-network-stream on error --]
[-- Type: text/x-patch, Size: 1904 bytes --]

Index: tls.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/tls.el,v
retrieving revision 7.5
diff -u -3 -b -r7.5 tls.el
--- tls.el	13 Feb 2005 04:44:40 -0000	7.5
+++ tls.el	8 Apr 2005 00:33:31 -0000
@@ -78,6 +78,20 @@
   :type 'regexp
   :group 'tls)
 
+(defcustom tls-refused "connect: Connection refused"
+  "*Regular expression indicating connection refused
+The default is what GNUTLS's \"gnutls-cli\" outputs."
+  :version "22.1"
+  :type 'regexp
+  :group 'tls)
+
+(defcustom tls-unresolvable "Cannot resolve "
+  "*Regular expression indicating unknown host name
+The default is what GNUTLS's \"gnutls-cli\" outputs."
+  :version "22.1"
+  :type 'regexp
+  :group 'tls)
+
 (defcustom tls-certtool-program (executable-find "certtool")
   "Name of  GnuTLS certtool.
 Used by `tls-certificate-information'."
@@ -138,11 +152,15 @@
 			      service)))))
 	     response)
 	(while (and process
-		    (memq (process-status process) '(open run))
 		    (save-excursion
 		      (set-buffer buffer) ;; XXX "blue moon" nntp.el bug
 		      (goto-char (point-min))
-		      (not (setq done (re-search-forward tls-success nil t)))))
+		      (when (re-search-forward tls-unresolvable nil t)
+			(error "Cannot resolve `%s'" host))
+		      (when (re-search-forward tls-refused nil t)
+			(error "Connection to `%s' refused" host))
+		      (not (setq done (re-search-forward tls-success nil t))))
+		    (memq (process-status process) '(open run)))
 	  (accept-process-output process 1)
 	  (sit-for 1))
 	(message "Opening TLS connection with `%s'...%s" cmd
@@ -152,6 +170,8 @@
 	  (delete-process process))))
     (message "Opening TLS connection to `%s'...%s"
 	     host (if done "done" "failed"))
+    (unless done
+      (error "Unknown error when connecting to `%s' -- is any `tls-program' installed?" host))
     done))
 
 (provide 'tls)

[-- Attachment #3: Type: text/plain, Size: 427 bytes --]


One problem with this code is that the caller must clean the buffer
before connection attempts, as messages matching tls-refused or
tls-unresolvable may stay there between connections.  I doubt
open-network-stream requires that.

If you don't think tls.el should have a patch like this, then the
comment claiming "Usage is the same as `open-network-stream'" should
be revised.

Thanks for looking at this again

  Carl Henrik