Mark Plaksin <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> 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)
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
