GNOME Bugzilla – Bug 775882
libsoup master branch causes breakage in libgdata.
Last modified: 2016-12-12 19:22:22 UTC
I tried libsoup from git master branch. commit a6d1d7aa49c264efc9d520ffe555299b7a92466e After that, libgdata started failing to authenticate against google. http://pastebin.com/raw/ZYhy2jmw Reverting to 2.56.0 fixed it.
presumably related to Carlos's auth-cache changes... if you could confirm that 8e1b0f5 works and efcb377 doesn't that would be great
Thank you. I tested. Revision 8e1b0f5 works and efcb377 doesn't.
The behavior when not using flag SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE should be the same, so there must be a bug. I think I know what's going on. libgdata builds the soup message with the Authorization header already set, and now we are always removing that header from auth_msg_starting.
Created attachment 341713 [details] [review] Do not remove Authorization header unconditionally The bug was actually introduced in the fix for the ntlm test crash. My patch tried to ensure the previous behavior but instead of removing the Auth header when the message had a SoupAuth (like we did before efcb377), I was checking if the given SoupAuth was null. So, the actual fix is checking if the message had a SoupAuth. This patch includes a new test case to check that we can provide our own Auth header when the session doesn't have any credentials cached, or when using the SOUP_MESSAGE_DO_NOT_USE_AUTH_CACHE flag. I won't be working next week, so feel free to commit this patch if it's good or revert the previous one otherwise to make libgdata work again.
Oops. I'd feel bad about having broken your patch with my fix, except that you submitted a patch that failed "make check" :-) Attachment 341713 [details] pushed as a8982b0 - Do not remove Authorization header unconditionally
I can verify it is working again. Thank you for the very quick fix.