It is currently described as a method as it takes a SoupURI as first parameter when typically functions foo_bar_new* are constructors.

https://bugzilla.gnome.org/show_bug.cgi?id=762138

Our third-party cookie blocking is too strict. Safari is the only major
browser that blocks third-party cookies by default, so the only way for
SOUP_COOKIE_JAR_ACCEPT_NO_THIRD_PARTY to be web compatible is for it to
match Safari as closely as possible. And Safari does not appear to
consider the full domain when deciding whether to block a third-party
cookie, it only considers the base domain. Reports indicate that Firefox
and Chrome behave similarly if the user chooses to block third-party
cookies in those browsers.

This fixes, in particular, notifications on google.com domains.

https://bugzilla.gnome.org/show_bug.cgi?id=792130

This is causing test failures in SPARC architectures.

https://bugzilla.gnome.org/show_bug.cgi?id=794421

When the client is using absolute paths for Digest authentication,
we need to make sure that the digest URI is not encoded before
comparing it to the request URI, as some clients might provide
URIs encoded and SoupURI might already have decoded the request
URI.

Also modify server-auth-test.c to make this problem reproducible
and add a couple of test cases to make sure we don't regress.

https://bugzilla.gnome.org/show_bug.cgi?id=794208