(url-retrieve-synchronously): Adjust the workaround so as not

to stop in the middle of a redirection.

diff --git a/lisp/url/ChangeLog b/lisp/url/ChangeLog
index 08d5eb4c6bfffc9661754372784c8802f3fc27f1..56d1faaa84d22a4b6dbde33b0f4acb675b744806 100644 (file)
--- a/lisp/url/ChangeLog
+++ b/lisp/url/ChangeLog
@@ -1,5 +1,8 @@
 2006-01-10  Stefan Monnier  <monnier@iro.umontreal.ca>
 
+       * url.el (url-retrieve-synchronously): Adjust the workaround so as not
+       to stop in the middle of a redirection.
+
        * url-vars.el (url-privacy-level): Add setter.
 
 2006-01-05  Stefan Monnier  <monnier@iro.umontreal.ca>

diff --git a/lisp/url/url.el b/lisp/url/url.el
index f9d06010171331f98ac959eb82930a5918823011..10c449cb30b78b602ab9104858ecb84df783fd61 100644 (file)
--- a/lisp/url/url.el
+++ b/lisp/url/url.el
@@ -190,11 +190,14 @@ no further processing).  URL is either a string or a parsed URL."
                     "Spinning in url-retrieve-synchronously: %S (%S)"
                     retrieval-done asynch-buffer)
          (if (and proc (memq (process-status proc)
-                              '(closed exit signal failed)))
+                              '(closed exit signal failed))
+                   ;; Make sure another process hasn't been started, as can
+                   ;; happen with http redirections.
+                  (eq proc (or (get-buffer-process asynch-buffer) proc)))
              ;; FIXME: It's not clear whether url-retrieve's callback is
              ;; guaranteed to be called or not.  It seems that url-http
              ;; decides sometimes consciously not to call it, so it's not
-             ;; clear that it's a bug, but even if we need to decide how
+             ;; clear that it's a bug, but even then we need to decide how
              ;; url-http can then warn us that the download has completed.
               ;; In the mean time, we use this here workaround.
               (setq retrieval-done t)