1
0
mirror of https://git.savannah.gnu.org/git/emacs.git synced 2024-11-23 07:19:15 +00:00

(url-http-handle-authentication): Don't kill the current buffer.

This commit is contained in:
Richard M. Stallman 2005-01-03 21:00:07 +00:00
parent 8a525646b0
commit 8ea5080e35

View File

@ -32,6 +32,9 @@ invalid pointer from string_free_list.
** Fix up url-ldap.el.
** url/*.el has lots of `(declare (special ...))' which
are meaningless. What's that trying to do?
* BUGS
** Incomplete overlay mouse-face highlight bug (Ralf Angeli, Oct 18)
@ -62,42 +65,6 @@ further.
I think in the near future we will see more of this problem, so it might be
time to make anfe-ftp more intelligent.
** Bug in url-http-parse-headers, reported in
From: Vivek Dasmohapatra <vivek@zeus.com>
Date: Tue, 28 Sep 2004 16:13:13 +0100
Fetching a url with url-retrieve can reult in an anrbitrary buffer
being killed if a 401 (or possibly a 407) result is encountered:
url-http-parse-headers calls url-http-handle-authentication,
which can call url-retrieve.
This results in the current buffer being killed, and a new http buffer
being generated. However, when the old http buffer is killed, emacs
picks the top buffer from the list as the new current buffer, so by the
time we get to the end of url-http-parse-headers, _that_ buffer is marked
as dead even though it is not necessarily a url buffer, so next time the
url libraries reap their dead buffers, an innocent bystander buffer is
killed instead (and an obsolete http buffer may be left lying around too).
A possible fix (which I am currently using) is to call set-buffer
on the return value of url-http-parse-headers:
(case url-http-response-status
(401
;; The request requires user authentication. The response
;; MUST include a WWW-Authenticate header field containing a
;; challenge applicable to the requested resource. The
;; client MAY repeat the request with a suitable
;; Authorization header field.
(url-mark-buffer-as-dead (current-buffer))
(set-buffer (url-http-handle-authentication nil)))
etc ....
which makes sure that it is the right http buffer that is current when
we come to mark the http buffers as dead.
* GTK RELATED BUGS