From: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Mon, 20 Feb 2006 21:54:23 +0000 (+0000)
Subject: (url-redirect-buffer): New var.
X-Git-Tag: emacs-pretest-22.0.90~3996
X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=9b4cf2318ae64f155a3101a332882dfa7197bc45;p=emacs.git

(url-redirect-buffer): New var.
(url-retrieve-synchronously): Use it to follow redirections.
---

diff --git a/lisp/url/ChangeLog b/lisp/url/ChangeLog
index 04cd080db8f..cb002731eec 100644
--- a/lisp/url/ChangeLog
+++ b/lisp/url/ChangeLog
@@ -1,3 +1,13 @@
+2006-02-20  Stefan Monnier  <monnier@iro.umontreal.ca>
+
+	* url.el (url-redirect-buffer): New var.
+	(url-retrieve-synchronously): Use it to follow redirections.
+
+	* url-http.el: Require `url' rather than try to autoload parts of it.
+	(url-http-find-free-connection): `url-open-stream' needs a real buffer.
+	(url-http-parse-headers): Set `url-redirect-buffer' when following
+	a redirection reply.
+
 2006-01-18  Stefan Monnier  <monnier@iro.umontreal.ca>
 
 	* url-news.el: Move defvars out of eval-when-compile.
@@ -18,7 +28,7 @@
 	(url-history-save-history): Create parent dir if necessary.
 	(url-history-save-history): Don't write the initialization of
 	url-history-hash-table into the history file.
-	(url-have-visited-url): Simplify since url-history-hash-table is non-nil.
+	(url-have-visited-url): Simplify since url-history-hash-table isn't nil.
 	(url-completion-function): Simplify.
 
 	* url-cookie.el (url-cookie-parse-file): Don't complain of missing file.
diff --git a/lisp/url/url.el b/lisp/url/url.el
index 10c449cb30b..07ac55dcd3d 100644
--- a/lisp/url/url.el
+++ b/lisp/url/url.el
@@ -114,6 +114,13 @@ Emacs."
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;; Retrieval functions
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
+(defvar url-redirect-buffer nil
+  "New buffer into which the retrieval will take place.
+Sometimes while retrieving a URL, the URL library needs to use another buffer
+than the one returned initially by `url-retrieve'.  In this case, it sets this
+variable in the original buffer as a forwarding pointer.")
+
 ;;;###autoload
 (defun url-retrieve (url callback &optional cbargs)
   "Retrieve URL asynchronously and call CALLBACK with CBARGS when finished.
@@ -189,18 +196,22 @@ no further processing).  URL is either a string or a parsed URL."
 	  (url-debug 'retrieval
 		     "Spinning in url-retrieve-synchronously: %S (%S)"
 		     retrieval-done asynch-buffer)
-	  (if (and proc (memq (process-status proc)
-                              '(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 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)
+          (if (buffer-local-value 'url-redirect-buffer asynch-buffer)
+              (setq proc (get-buffer-process
+                          (setq asynch-buffer
+                                (buffer-local-value 'url-redirect-buffer
+                                                    asynch-buffer))))
+            (if (and proc (memq (process-status proc)
+                                '(closed exit signal failed))
+                     ;; Make sure another process hasn't been started.
+                     (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 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))
             ;; We used to use `sit-for' here, but in some cases it wouldn't
             ;; work because apparently pending keyboard input would always
             ;; interrupt it before it got a chance to handle process input.