Re: HTTP redirects make url-retrieve-synchronously asynchronous

[Mark Plaksin]

Mark Plaksin <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>
>> Funny, now that you mention it, I see in the piece of code that does what
>> you describe.  I'll have to try again and figure out why it seemed to work
>> for me.
>
> It works great as long as keep-alive is in effect.  The Slashdot redirect
> has "Connection: close" in the headers--that makes it fail as I described.
> I've done lots of testing and turning keep-alive off (either in the site's
> response headers or by setting url-http-attempt-keepalives to nil) is the
> only way I can make your fix fail.
>
> I'll keep poking around and see if I can figure out why that is the case.
> Feel free to beat me to it! :)

It might not be elegant but the attached patch works for me.  If
url-retrieve sees :redirect in cbargs, it calls url-retrieve-synchronously
and then calls the callback with cbargs.

--- /home/happy/src/emacs/multi-tty/lisp/url/url.el     2006-01-03 
11:06:25.000000000 -0500
+++ lisp/url/url.el     2006-01-10 15:31:55.000000000 -0500
@@ -190,11 +190,14 @@
                     "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)