#SoupSession is the object that controls client-side HTTP. A
#SoupSession encapsulates all of the state that libsoup is keeping
on behalf of your program; cached HTTP connections, authentication
information, etc. It also keeps track of various global options
and features that you are using.
Most applications will only need a single #SoupSession; the primary
reason you might need multiple sessions is if you need to have
multiple independent authentication contexts. (Eg, you are
connecting to a server and authenticating as two different users at
different times; the easiest way to ensure that each class@Message
is sent with the authentication information you intended is to use
one session for the first user, and a second session for the other
user.)
Additional #SoupSession functionality is provided by
iface@SessionFeature objects, which can be added to a session with
soup.session.Session.addFeature or soup.session.Session.addFeatureByType
For example, class@Logger provides support for
logging HTTP traffic, class@ContentDecoder provides support for
compressed response handling, and class@ContentSniffer provides
support for HTML5-style response body content sniffing.
Additionally, subtypes of class@Auth can be added
as features, to add support for additional authentication types.
All soup.session.Sessions are created with a class@AuthManager, and support
for SOUP_TYPE_AUTH_BASIC and SOUP_TYPE_AUTH_DIGEST. Additionally,
sessions using the plain #SoupSession class (rather than one of its deprecated
subtypes) have a class@ContentDecoder by default.
Note that all async methods will invoke their callbacks on the thread-default
context at the time of the function call.
Soup session state object.
#SoupSession is the object that controls client-side HTTP. A #SoupSession encapsulates all of the state that libsoup is keeping on behalf of your program; cached HTTP connections, authentication information, etc. It also keeps track of various global options and features that you are using.
Most applications will only need a single #SoupSession; the primary reason you might need multiple sessions is if you need to have multiple independent authentication contexts. (Eg, you are connecting to a server and authenticating as two different users at different times; the easiest way to ensure that each class@Message is sent with the authentication information you intended is to use one session for the first user, and a second session for the other user.)
Additional #SoupSession functionality is provided by iface@SessionFeature objects, which can be added to a session with soup.session.Session.addFeature or soup.session.Session.addFeatureByType For example, class@Logger provides support for logging HTTP traffic, class@ContentDecoder provides support for compressed response handling, and class@ContentSniffer provides support for HTML5-style response body content sniffing. Additionally, subtypes of class@Auth can be added as features, to add support for additional authentication types.
All soup.session.Sessions are created with a class@AuthManager, and support for SOUP_TYPE_AUTH_BASIC and SOUP_TYPE_AUTH_DIGEST. Additionally, sessions using the plain #SoupSession class (rather than one of its deprecated subtypes) have a class@ContentDecoder by default.
Note that all async methods will invoke their callbacks on the thread-default context at the time of the function call.