Subject: bug#11981: closed (Re: bug#11981: 24.1.50; url-http-parse-headers should not disable file name handlers since it breaks auth-source)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 14 Aug 2012 15:05:02 +0000

Your bug report

#11981: 24.1.50; url-http-parse-headers should not disable file name handlers since it breaks auth-source

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
11981: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11981
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#11981: 24.1.50; url-http-parse-headers should not disable file name handlers since it breaks auth-source
From: Stefan Monnier <[email-masked]>
To: David Engster <[email-masked]>
Cc: [email-masked], Jan Djärv <[email-masked]>, Michael Albinus <[email-masked]>
Date: Tue, 14 Aug 2012 10:55:39 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

>> Can we now re-enable file-name-handlers in url-http-parse-headers?

> I think so. I re-enabled the file-name-handlers, created a test feed
> with a colon in it
> http://www.randomsample.de/foo:bar.xml
> and I could subscribe to it with Gnus (the original URLs in Bug #6717
> gave me http 405 errors).

OK, re-enabled, then, thank you,

        Stefan

Subject: 24.1.50; url-http-parse-headers should not disable file name handlers since it breaks auth-source
From: David Engster <[email-masked]>
To: [email-masked]
Date: Wed, 18 Jul 2012 20:38:48 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

The function `url-http-parse-headers' temporarily disables all file name
handlers to circumvent a bug where Tramp could kick in because the URL
might look like a remote file (#6717). This is the offending snippet:

	;; The filename part of a URL could be in remote file syntax,
	;; see Bug#6717 for an example.  We disable file name
	;; handlers, therefore.
	(file-name-handler-alist nil))

However, this workaraound assumes that everything that gets afterwards
in the `let'-section does not depend on file name handlers. However,
this is not the case: `url-http-handle-authentication' is called which
in turn calls the auth-source package. This package however supports
encrypted authinfo files which have to be automatically decrypted
through `auto-encryption-mode'. This, of course, works through file name
handlers.

Here's a backtrace from `auth-source-search' resulting from a call to
`url-retrieve-synchronously' on a password-protected URL:

  auth-source-search(:max 1 :host "www.google.com:443" :port "https")
  url-do-auth-source-search("www.google.com:443" "https" :user)
  url-basic-auth([cl-struct-url "https" nil nil "www.google.com" 443  "/calendar/dav/MY-GOOGLE-ACCOUNT/events/" nil nil t nil t] t nil "Google CalDAV" (("realm" . "Google CalDAV") ("basic")))
  url-get-authentication("https://www.google.com/calendar/dav/MY-GOOGLE-ACCOUNT/events/" "Google CalDAV" "basic" t (("realm" . "Google CalDAV") ("basic")))
  url-http-handle-authentication(nil)
  [ ... ]
  url-http-parse-headers()
  url-http-chunked-encoding-after-change-function(500 507 7)
  url-http-generic-filter(#<process www.google.com<1>> "\n0\n\n")
  [ ... ]
  url-retrieve-synchronously("https://www.google.com/calendar/dav/MY-GOOGLE-ACCOUNT/events/")

Note that after `url-http-parse-headers' the variable
`file-name-handler-alist' is set to 'nil', thus when
`auth-source-search' loads an encrypted authinfo.gpg file, it won't
automatically get decrypted.

-David