GNU bug report logs - #72652
31.0.50; url-retrieve on non-existent domain gives no indication of error

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Greg Minshall <minshall <at> umich.edu>
Cc: 72652 <at> debbugs.gnu.org
Subject: bug#72652: 31.0.50; url-retrieve on non-existent domain gives no indication of error
Date: Sat, 17 Aug 2024 08:50:23 +0300

> cc: 72652 <at> debbugs.gnu.org
> From: Greg Minshall <minshall <at> umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz <at> gnu.org>
>    message dated "Fri, 16 Aug 2024 10:43:30 +0300."
> Date: Fri, 16 Aug 2024 22:39:11 +0300
> 
> > On MS-Windows (mytry 2) signals an error:
> 
> i see.  possibly the Emacs on windows is using a synchronous DNS
> resolver (possibly not).

Yes, I think so.

> the problem is that there's no indication from url-retrieve that the
> requested transfer has failed (or has in any way finished).  the only
> reason the message about the buffer was printed out was because the
> mytry script times out after 5 seconds, prints out whatever might be in
> the buffer.
> 
> so, a program that calls url-retrieve for an unknown host is never
> notified that anything happened.
> 
> 
> if some sort of error is detected synchronous with the call to
> url-retrieve (i.e., before url-retrieve returns to its caller),
> signaling an error seems fine.
> 
> in the case where the error is detected later, then i think (if
> possible) url-retrieve should cause a callback to happen, with the
> `:error` data in the status parameter specifying something like "unknown
> host".
> 
> in the case of (mytry 1), there is a callback (to the callback routine
> specified in the invocation of url-retrieve) which passes an error
> indication:
> ----
> called back: ((:error (error http 500)
> ----
> (one can modify mytry to print out the status given to the
> callback routine -- see below.)

Patches to report an error in the (mytry 2) case are welcome.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.