meh. evolution is probably doing something vaguely wrongish here, but
presumably other code might be doing the same thing, so I've reverted
the change. Thanks for bisecting it.

Hmm, I thought CalDAV [1] itself does something wrong here, but it even doesn't read the password from the URL, thus it might be something else probably (some other part of evolution). Or, the URL as is constructed. If you write the empty password into URL when converting SoupURI into a string, and the libsoup later doesn't ask for a user password, because it thinks it's part of the URL already, then maybe it's it?

[1] http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/caldav/e-cal-backend-caldav.c

Yeah, i couldn't figure out where uri->password was getting read from...

But I think I figured out what's happening; evolution is requesting a URL something like "http://username@example.com/my/calendar/", and in the old libsoup, since there was no password specified, libsoup would ignore the username, and so when it got a 401, it would immediately emit authenticate. But with 2.41.4, that URL got parsed as having a password of "", and so libsoup would try to authenticate using that password first, and fail, and then emit authenticate with retrying=TRUE, which made evo think the saved password had failed.

Something like that anyway.

I agree. I was aiming in the same scenario too.