Porting to the new SoupSession
Porting to the new SoupSession — Notes on porting from SoupSessionAsync and SoupSessionSync to SoupSession
There are several changes in behavior between the old and new sessions to be aware of.
property defaults to
NULL, meaning that URI
schemes like "
dav" (and "
ftp") are not
considered to be aliases for "
http", and so
libsoup will not accept requests for such URIs, and will not
follow redirects to such URIs.
property is now initialized to the default
meaning that it will automatically use the user's system proxy
configuration. This replaces the use of the
session feature in earlier releases. You can set this property to
NULL if you don't want to use proxies, and the
property still works if you want to use a single proxy for all requests.
Every session gets a SoupContentDecoder attached to it by default, meaning that it will automatically handle (and request) "gzip"- and "deflate"-encoded response bodies.
If you are using NTLM authentication, the new SoupSession behaves slightly differently from the old session types.
Second, with the old session types, enabling NTLM would cause all
(otherwise-unauthenticated) requests to be sent with an NTLM request
Authorization header. That is, libsoup would
assume that all servers supported NTLM, and would attempt to begin
negotiating NTLM authentication before the server ever returned a 401
response. With the plain SoupSession, this no longer
happens. If you want the old behavior, you need to call
for each host to "preload" the NTLM authentication:
1 2 3 4 5 6 7 8 9 10
SoupAuthManager *auth_manager; SoupAuth *auth; SoupURI *uri; auth_manager = SOUP_AUTH_MANAGER (soup_session_get_feature (session, SOUP_TYPE_AUTH_MANAGER)); auth = g_object_new (SOUP_TYPE_AUTH_NTLM, NULL); uri = soup_uri_new ("http://ntlm-using-host.example.com/"); soup_auth_manager_use_auth (auth_manager, uri, auth); g_object_unref (auth); soup_uri_free (auth);
SoupSessionAsync always uses asynchronous I/O, and
SoupSessionSync always uses blocking I/O, regardless of
the operation. In the new SoupSession,
uses asynchronous I/O (like SoupSessionAsync), and
uses blocking I/O (like SoupSessionSync). There is no API
on the plain SoupSession that simulates the effect of
soup_session_send_message() on a
SoupSessionAsync (ie, running the main loop internally),
or of calling
soup_session_queue_message() on a
SoupSessionSync (ie, automatically sending the request in
In particular, the "async-context" and "use-thread-context" properties are now effectively unused, and the session always queues asynchronous requests in the GMainContext that was is the thread default when the asynchronous operation is started. Session bookkeeping tasks (like closing idle connections) happen in the context that was thread default when the session was created.
now acts asynchronously when you cancel an asynchronous request;
rather than having the request's callback be called from inside
soup_session_cancel_message(), it just gets called
when you need return to the main loop.