Top |
Functions
Properties
SoupURI * | first-party | Read / Write |
SoupMessageFlags | flags | Read / Write |
SoupHTTPVersion | http-version | Read / Write |
gboolean | is-top-level-navigation | Read / Write |
gchar * | method | Read / Write |
SoupMessagePriority | priority | Read / Write |
gchar * | reason-phrase | Read / Write |
SoupMessageBody * | request-body | Read |
GBytes * | request-body-data | Read |
SoupMessageHeaders * | request-headers | Read |
SoupMessageBody * | response-body | Read |
GBytes * | response-body-data | Read |
SoupMessageHeaders * | response-headers | Read |
gboolean | server-side | Read / Write / Construct Only |
SoupURI * | site-for-cookies | Read / Write |
guint | status-code | Read / Write |
GTlsCertificate * | tls-certificate | Read / Write |
GTlsCertificateFlags | tls-errors | Read / Write |
SoupURI * | uri | Read / Write |
Signals
void | content-sniffed | Run First |
void | finished | Run First |
void | got-body | Run First |
void | got-chunk | Run First |
void | got-headers | Run First |
void | got-informational | Run First |
void | network-event | Run First |
void | restarted | Run First |
void | starting | Run First |
void | wrote-body | Run First |
void | wrote-body-data | Run First |
void | wrote-chunk | Run First |
void | wrote-headers | Run First |
void | wrote-informational | Run First |
Types and Values
SoupMessage | |
enum | SoupHTTPVersion |
enum | SoupMessageFlags |
enum | SoupMessagePriority |
#define | SOUP_MESSAGE_METHOD |
#define | SOUP_MESSAGE_URI |
#define | SOUP_MESSAGE_HTTP_VERSION |
#define | SOUP_MESSAGE_FLAGS |
#define | SOUP_MESSAGE_STATUS_CODE |
#define | SOUP_MESSAGE_REASON_PHRASE |
#define | SOUP_MESSAGE_SERVER_SIDE |
#define | SOUP_MESSAGE_FIRST_PARTY |
#define | SOUP_MESSAGE_PRIORITY |
#define | SOUP_MESSAGE_REQUEST_BODY |
#define | SOUP_MESSAGE_REQUEST_BODY_DATA |
#define | SOUP_MESSAGE_REQUEST_HEADERS |
#define | SOUP_MESSAGE_RESPONSE_BODY |
#define | SOUP_MESSAGE_RESPONSE_BODY_DATA |
#define | SOUP_MESSAGE_RESPONSE_HEADERS |
#define | SOUP_MESSAGE_TLS_CERTIFICATE |
#define | SOUP_MESSAGE_TLS_ERRORS |
Description
A SoupMessage represents an HTTP message that is being sent or received.
For client-side usage, if you are using the traditional
SoupSession APIs (soup_session_queue_message()
and
soup_session_send_message()
), you would create a SoupMessage with
soup_message_new()
or soup_message_new_from_uri()
, set up its
fields appropriately, and send it. If you are using the newer
SoupRequest API, you would create a request with
soup_session_request_http()
or soup_session_request_http_uri()
, and
the returned SoupRequestHTTP will already have an associated
SoupMessage that you can retrieve via
soup_request_http_get_message()
.
For server-side usage, SoupServer will create SoupMessages automatically for incoming requests, which your application will receive via handlers.
Note that libsoup's terminology here does not quite match the HTTP specification: in RFC 2616, an "HTTP-message" is either a Request, or a Response. In libsoup, a SoupMessage combines both the request and the response.
Functions
soup_message_new ()
SoupMessage * soup_message_new (const char *method
,const char *uri_string
);
Creates a new empty SoupMessage, which will connect to uri
soup_message_new_from_uri ()
SoupMessage * soup_message_new_from_uri (const char *method
,SoupURI *uri
);
Creates a new empty SoupMessage, which will connect to uri
Parameters
method |
the HTTP method for the created request |
|
uri |
the destination endpoint (as a SoupURI) |
soup_message_set_request ()
void soup_message_set_request (SoupMessage *msg
,const char *content_type
,SoupMemoryUse req_use
,const char *req_body
,gsize req_length
);
Convenience function to set the request body of a SoupMessage. If
content_type
is NULL
, the request body must be empty as well.
Parameters
msg |
the message |
|
content_type |
MIME Content-Type of the body. |
[allow-none] |
req_use |
a SoupMemoryUse describing how to handle |
|
req_body |
a data buffer containing the body of the message request. |
[allow-none][array length=req_length][element-type guint8] |
req_length |
the byte length of |
soup_message_set_response ()
void soup_message_set_response (SoupMessage *msg
,const char *content_type
,SoupMemoryUse resp_use
,const char *resp_body
,gsize resp_length
);
Convenience function to set the response body of a SoupMessage. If
content_type
is NULL
, the response body must be empty as well.
Parameters
msg |
the message |
|
content_type |
MIME Content-Type of the body. |
[allow-none] |
resp_use |
a SoupMemoryUse describing how to handle |
|
resp_body |
a data buffer containing the body of the message response. |
[allow-none][array length=resp_length][element-type guint8] |
resp_length |
the byte length of |
soup_message_set_http_version ()
void soup_message_set_http_version (SoupMessage *msg
,SoupHTTPVersion version
);
Sets the HTTP version on msg
. The default version is
SOUP_HTTP_1_1
. Setting it to SOUP_HTTP_1_0
will prevent certain
functionality from being used.
soup_message_get_http_version ()
SoupHTTPVersion
soup_message_get_http_version (SoupMessage *msg
);
Gets the HTTP version of msg
. This is the minimum of the
version from the request and the version from the response.
soup_message_set_uri ()
void soup_message_set_uri (SoupMessage *msg
,SoupURI *uri
);
Sets msg
's URI to uri
. If msg
has already been sent and you want
to re-send it with the new URI, you need to call
soup_session_requeue_message()
.
soup_message_get_address ()
SoupAddress *
soup_message_get_address (SoupMessage *msg
);
Gets the address msg
's URI points to. After first setting the
URI on a message, this will be unresolved, although the message's
session will resolve it before sending the message.
Since: 2.26
soup_message_set_status ()
void soup_message_set_status (SoupMessage *msg
,guint status_code
);
Sets msg
's status code to status_code
. If status_code
is a
known value, it will also set msg
's reason_phrase.
soup_message_set_status_full ()
void soup_message_set_status_full (SoupMessage *msg
,guint status_code
,const char *reason_phrase
);
Sets msg
's status code and reason phrase.
soup_message_set_redirect ()
void soup_message_set_redirect (SoupMessage *msg
,guint status_code
,const char *redirect_uri
);
Sets msg
's status_code to status_code
and adds a Location header
pointing to redirect_uri
. Use this from a SoupServer when you
want to redirect the client to another URI.
redirect_uri
can be a relative URI, in which case it is
interpreted relative to msg
's current URI. In particular, if
redirect_uri
is just a path, it will replace the path
and query of msg
's URI.
Since: 2.38
soup_message_is_keepalive ()
gboolean
soup_message_is_keepalive (SoupMessage *msg
);
Determines whether or not msg
's connection can be kept alive for
further requests after processing msg
, based on the HTTP version,
Connection header, etc.
soup_message_get_https_status ()
gboolean soup_message_get_https_status (SoupMessage *msg
,GTlsCertificate **certificate
,GTlsCertificateFlags *errors
);
If msg
is using https (or attempted to use https but got
SOUP_STATUS_SSL_FAILED
), this retrieves the GTlsCertificate
associated with its connection, and the GTlsCertificateFlags
showing what problems, if any, have been found with that
certificate.
This is only meaningful with messages processed by a SoupSession and is not useful for messages received by a SoupServer
Parameters
msg |
||
certificate |
|
[out][transfer none] |
errors |
the verification status of |
[out] |
Since: 2.34
soup_message_set_first_party ()
void soup_message_set_first_party (SoupMessage *msg
,SoupURI *first_party
);
Sets first_party
as the main document SoupURI for msg
. For
details of when and how this is used refer to the documentation for
SoupCookieJarAcceptPolicy.
Since: 2.30
soup_message_get_first_party ()
SoupURI *
soup_message_get_first_party (SoupMessage *msg
);
Gets msg
's first-party SoupURI
Since: 2.30
soup_message_add_header_handler ()
guint soup_message_add_header_handler (SoupMessage *msg
,const char *signal
,const char *header
,GCallback callback
,gpointer user_data
);
Adds a signal handler to msg
for signal
, as with
g_signal_connect()
, but the callback
will only be run if msg
's
incoming messages headers (that is, the
request_headers
for a client SoupMessage, or
the response_headers
for a server SoupMessage)
contain a header named header
.
[skip]
soup_message_add_status_code_handler ()
guint soup_message_add_status_code_handler (SoupMessage *msg
,const char *signal
,guint status_code
,GCallback callback
,gpointer user_data
);
Adds a signal handler to msg
for signal
, as with
g_signal_connect()
, but the callback
will only be run if msg
has
the status status_code
.
signal
must be a signal that will be emitted after msg
's status
is set. For a client SoupMessage, this means it can't be a "wrote"
signal. For a server SoupMessage, this means it can't be a "got"
signal.
[skip]
soup_message_set_flags ()
void soup_message_set_flags (SoupMessage *msg
,SoupMessageFlags flags
);
Sets the specified flags on msg
.
soup_message_get_flags ()
SoupMessageFlags
soup_message_get_flags (SoupMessage *msg
);
Gets the flags on msg
SoupChunkAllocator ()
SoupBuffer * (*SoupChunkAllocator) (SoupMessage *msg
,gsize max_len
,gpointer user_data
);
SoupChunkAllocator
is deprecated and should not be used in newly-written code.
Use SoupRequest if you want to read into your own buffers.
The prototype for a chunk allocation callback. This should allocate a new SoupBuffer and return it for the I/O layer to read message body data off the network into.
If max_len
is non-0, it indicates the maximum number of bytes that
could be read, based on what is known about the message size. Note
that this might be a very large number, and you should not simply
try to allocate that many bytes blindly. If max_len
is 0, that
means that libsoup does not know how many bytes remain to be read,
and the allocator should return a buffer of a size that it finds
convenient.
If the allocator returns NULL
, the message will be paused. It is
up to the application to make sure that it gets unpaused when it
becomes possible to allocate a new buffer.
Parameters
msg |
the SoupMessage the chunk is being allocated for |
|
max_len |
the maximum length that will be read, or 0. |
|
user_data |
the data passed to |
soup_message_disable_feature ()
void soup_message_disable_feature (SoupMessage *msg
,GType feature_type
);
This disables the actions of SoupSessionFeatures with the
given feature_type
(or a subclass of that type) on msg
, so that
msg
is processed as though the feature(s) hadn't been added to the
session. Eg, passing SOUP_TYPE_CONTENT_SNIFFER for feature_type
will disable Content-Type sniffing on the message.
You must call this before queueing msg
on a session; calling it on
a message that has already been queued is undefined. In particular,
you cannot call this on a message that is being requeued after a
redirect or authentication.
Since: 2.28
soup_message_is_feature_disabled ()
gboolean soup_message_is_feature_disabled (SoupMessage *msg
,GType feature_type
);
Get whether SoupSessionFeatures of the given feature_type
(or a subclass of that type) are disabled on msg
.
See soup_message_disable_feature()
.
Since: 2.72
soup_message_get_soup_request ()
SoupRequest *
soup_message_get_soup_request (SoupMessage *msg
);
If msg
is associated with a SoupRequest, this returns that
request. Otherwise it returns NULL
.
Since: 2.42
soup_message_get_priority ()
SoupMessagePriority
soup_message_get_priority (SoupMessage *msg
);
Retrieves the SoupMessagePriority. If not set this value defaults to SOUP_MESSAGE_PRIORITY_NORMAL.
Since: 2.44
soup_message_set_priority ()
void soup_message_set_priority (SoupMessage *msg
,SoupMessagePriority priority
);
Sets the priority of a message. Note that this won't have any effect unless used before the message is added to the session's message processing queue.
The message will be placed just before any other previously added message with lower priority (messages with the same priority are processed on a FIFO basis).
Setting priorities does not currently work with SoupSessionSync (or with synchronous messages on a plain SoupSession) because in the synchronous/blocking case, priority ends up being determined semi-randomly by thread scheduling.
Since: 2.44
soup_message_get_site_for_cookies ()
SoupURI *
soup_message_get_site_for_cookies (SoupMessage *msg
);
Gets msg
's site for cookies SoupURI
Since: 2.70
soup_message_set_site_for_cookies ()
void soup_message_set_site_for_cookies (SoupMessage *msg
,SoupURI *site_for_cookies
);
Sets site_for_cookies
as the policy URL for same-site cookies for msg
.
It is either the URL of the top-level document or NULL
depending on whether the registrable
domain of this document's URL matches the registrable domain of its parent's/opener's
URL. For the top-level document it is set to the document's URL.
See the same-site spec for more information.
Since: 2.70
soup_message_get_is_top_level_navigation ()
gboolean
soup_message_get_is_top_level_navigation
(SoupMessage *msg
);
Since: 2.70
soup_message_set_is_top_level_navigation ()
void soup_message_set_is_top_level_navigation (SoupMessage *msg
,gboolean is_top_level_navigation
);
See the same-site spec for more information.
Parameters
msg |
||
is_top_level_navigation |
if |
Since: 2.70
Types and Values
SoupMessage
typedef struct { const char *method; guint status_code; char *reason_phrase; SoupMessageBody *request_body; SoupMessageHeaders *request_headers; SoupMessageBody *response_body; SoupMessageHeaders *response_headers; } SoupMessage;
Represents an HTTP message being sent or received.
status_code
will normally be a SoupStatus value, eg,
SOUP_STATUS_OK
, though of course it might actually be an unknown
status code. reason_phrase
is the actual text returned from the
server, which may or may not correspond to the "standard"
description of status_code
. At any rate, it is almost certainly
not localized, and not very descriptive even if it is in the user's
language; you should not use reason_phrase
in user-visible
messages. Rather, you should look at status_code
, and determine an
end-user-appropriate message based on that and on what you were
trying to do.
As described in the SoupMessageBody documentation, the
request_body
and response_body
data
fields
will not necessarily be filled in at all times. When the body
fields are filled in, they will be terminated with a '\0' byte
(which is not included in the length
), so you
can use them as ordinary C strings (assuming that you know that the
body doesn't have any other '\0' bytes).
For a client-side SoupMessage, request_body
's
data
is usually filled in right before libsoup
writes the request to the network, but you should not count on
this; use soup_message_body_flatten()
if you want to ensure that
data
is filled in. If you are not using
SoupRequest to read the response, then response_body
's
data
will be filled in before
“finished” is emitted. (If you are using SoupRequest,
then the message body is not accumulated by default, so
response_body
's data
will always be NULL
.)
For a server-side SoupMessage, request_body
's data
will be
filled in before “got_body” is emitted.
To prevent the data
field from being filled in at all (eg, if you
are handling the data from a “got_chunk”, and so don't
need to see it all at the end), call
soup_message_body_set_accumulate()
on response_body
or
request_body
as appropriate, passing FALSE
.
Members
the HTTP method |
||
the HTTP status code |
||
the status phrase associated with |
||
SoupMessageBody * |
the request body |
|
SoupMessageHeaders * |
the request headers |
|
SoupMessageBody * |
the response body |
|
SoupMessageHeaders * |
the response headers |
enum SoupMessageFlags
Various flags that can be set on a SoupMessage to alter its behavior.
Members
The session should not follow redirect (3xx) responses received by this message. |
||
The caller will rebuild the request
body if the message is restarted; see
|
||
Deprecated: equivalent to calling
|
||
Set by SoupContentDecoder to indicate that it has removed the Content-Encoding on a message (and so headers such as Content-Length may no longer accurately describe the body). |
||
if set after an https response has been received, indicates that the server's SSL certificate is trusted according to the session's CA. |
||
Requests that the message should be sent on a newly-created connection, not reusing an existing persistent connection. Note that messages with non-idempotent “method”s behave this way by default, unless SOUP_MESSAGE_IDEMPOTENT is set. |
||
The message is considered idempotent, regardless its “method”, and allows reuse of existing idle connections, instead of always requiring a new one, unless SOUP_MESSAGE_NEW_CONNECTION is set. |
||
Request that a new connection is created for the message if there aren't idle connections available and it's not possible to create new connections due to any of the connection limits has been reached. If a dedicated connection is eventually created for this message, it will be dropped when the message finishes. Since 2.50 |
||
The SoupAuthManager should not use
the credentials cache for this message, neither to use cached credentials
to automatically authenticate this message nor to cache the credentials
after the message is successfully authenticated. This applies to both server
and proxy authentication. Note that “authenticate” signal will
be emitted, if you want to disable authentication for a message use
|
enum SoupMessagePriority
Priorities that can be set on a SoupMessage to instruct the message queue to process it before any other message with lower priority.
Members
The lowest priority, the messages with this priority will be the last ones to be attended. |
||
Use this for low priority messages, a SoupMessage with the default priority will be processed first. |
||
The default priotity, this is the priority assigned to the SoupMessage by default. |
||
High priority, a SoupMessage with this priority will be processed before the ones with the default priority. |
||
The highest priority, use this for very urgent SoupMessage as they will be the first ones to be attended. |
SOUP_MESSAGE_METHOD
#define SOUP_MESSAGE_METHOD "method"
Alias for the “method” property. (The message's HTTP method.)
SOUP_MESSAGE_HTTP_VERSION
#define SOUP_MESSAGE_HTTP_VERSION "http-version"
Alias for the “http-version” property. (The message's SoupHTTPVersion.)
SOUP_MESSAGE_FLAGS
#define SOUP_MESSAGE_FLAGS "flags"
Alias for the “flags” property. (The message's SoupMessageFlags.)
SOUP_MESSAGE_STATUS_CODE
#define SOUP_MESSAGE_STATUS_CODE "status-code"
Alias for the “status-code” property. (The message's HTTP response status code.)
SOUP_MESSAGE_REASON_PHRASE
#define SOUP_MESSAGE_REASON_PHRASE "reason-phrase"
Alias for the “reason-phrase” property. (The message's HTTP response reason phrase.)
SOUP_MESSAGE_SERVER_SIDE
#define SOUP_MESSAGE_SERVER_SIDE "server-side"
Alias for the “server-side” property. (TRUE
if
the message was created by SoupServer.)
SOUP_MESSAGE_FIRST_PARTY
#define SOUP_MESSAGE_FIRST_PARTY "first-party"
Alias for the “first-party” property. (The SoupURI loaded in the application when the message was queued.)
Since: 2.30
SOUP_MESSAGE_PRIORITY
#define SOUP_MESSAGE_PRIORITY "priority"
Sets the priority of the SoupMessage. See
soup_message_set_priority()
for further details.
Since: 2.44
SOUP_MESSAGE_REQUEST_BODY
#define SOUP_MESSAGE_REQUEST_BODY "request-body"
Alias for the “request-body” property. (The message's HTTP request body.)
SOUP_MESSAGE_REQUEST_BODY_DATA
#define SOUP_MESSAGE_REQUEST_BODY_DATA "request-body-data"
Alias for the “request-body-data” property. (The message's HTTP request body, as a GBytes.)
Since: 2.46
SOUP_MESSAGE_REQUEST_HEADERS
#define SOUP_MESSAGE_REQUEST_HEADERS "request-headers"
Alias for the “request-headers” property. (The message's HTTP request headers.)
SOUP_MESSAGE_RESPONSE_BODY
#define SOUP_MESSAGE_RESPONSE_BODY "response-body"
Alias for the “response-body” property. (The message's HTTP response body.)
SOUP_MESSAGE_RESPONSE_BODY_DATA
#define SOUP_MESSAGE_RESPONSE_BODY_DATA "response-body-data"
Alias for the “response-body-data” property. (The message's HTTP response body, as a GBytes.)
Since: 2.46
SOUP_MESSAGE_RESPONSE_HEADERS
#define SOUP_MESSAGE_RESPONSE_HEADERS "response-headers"
Alias for the “response-headers” property. (The message's HTTP response headers.)
SOUP_MESSAGE_TLS_CERTIFICATE
#define SOUP_MESSAGE_TLS_CERTIFICATE "tls-certificate"
Alias for the “tls-certificate” property. (The TLS certificate associated with the message, if any.)
Since: 2.34
SOUP_MESSAGE_TLS_ERRORS
#define SOUP_MESSAGE_TLS_ERRORS "tls-errors"
Alias for the “tls-errors” property. (The verification errors on “tls-certificate”.)
Since: 2.34
Property Details
The “first-party”
property
“first-party” SoupURI *
The SoupURI loaded in the application when the message was queued.
Owner: SoupMessage
Flags: Read / Write
Since: 2.30
The “flags”
property
“flags” SoupMessageFlags
Various message options.
Owner: SoupMessage
Flags: Read / Write
The “http-version”
property
“http-version” SoupHTTPVersion
The HTTP protocol version to use.
Owner: SoupMessage
Flags: Read / Write
Default value: SOUP_HTTP_1_1
The “is-top-level-navigation”
property
“is-top-level-navigation” gboolean
Set when the message is navigating between top level domains.
Owner: SoupMessage
Flags: Read / Write
Default value: FALSE
Since: 2.70
The “method”
property
“method” gchar *
The message's HTTP method.
Owner: SoupMessage
Flags: Read / Write
Default value: "GET"
The “priority”
property
“priority” SoupMessagePriority
The priority of the message.
Owner: SoupMessage
Flags: Read / Write
Default value: SOUP_MESSAGE_PRIORITY_NORMAL
The “reason-phrase”
property
“reason-phrase” gchar *
The HTTP response reason phrase.
Owner: SoupMessage
Flags: Read / Write
Default value: NULL
The “request-body”
property
“request-body” SoupMessageBody *
The HTTP request content.
Owner: SoupMessage
Flags: Read
The “request-body-data”
property
“request-body-data” GBytes *
The message's HTTP request body, as a GBytes.
Owner: SoupMessage
Flags: Read
Since: 2.46
The “request-headers”
property
“request-headers” SoupMessageHeaders *
The HTTP request headers.
Owner: SoupMessage
Flags: Read
The “response-body”
property
“response-body” SoupMessageBody *
The HTTP response content.
Owner: SoupMessage
Flags: Read
The “response-body-data”
property
“response-body-data” GBytes *
The message's HTTP response body, as a GBytes.
Owner: SoupMessage
Flags: Read
Since: 2.46
The “response-headers”
property
“response-headers” SoupMessageHeaders *
The HTTP response headers.
Owner: SoupMessage
Flags: Read
The “server-side”
property
“server-side” gboolean
Whether or not the message is server-side rather than client-side.
Owner: SoupMessage
Flags: Read / Write / Construct Only
Default value: FALSE
The “site-for-cookies”
property
“site-for-cookies” SoupURI *
The URI for the site to compare cookies against.
Owner: SoupMessage
Flags: Read / Write
The “status-code”
property
“status-code” guint
The HTTP response status code.
Owner: SoupMessage
Flags: Read / Write
Allowed values: <= 999
Default value: 0
The “tls-certificate”
property
“tls-certificate” GTlsCertificate *
The GTlsCertificate associated with the message
Owner: SoupMessage
Flags: Read / Write
Since: 2.34
The “tls-errors”
property
“tls-errors” GTlsCertificateFlags
The verification errors on “tls-certificate”
Owner: SoupMessage
Flags: Read / Write
Since: 2.34
The “uri”
property
“uri” SoupURI *
The message's Request-URI.
Owner: SoupMessage
Flags: Read / Write
Signal Details
The “content-sniffed”
signal
void user_function (SoupMessage *msg, gchar *type, GHashTable *params, gpointer user_data)
This signal is emitted after “got-headers”, and
before the first “got-chunk”. If content
sniffing is disabled, or no content sniffing will be
performed, due to the sniffer deciding to trust the
Content-Type sent by the server, this signal is emitted
immediately after “got-headers”, and type
is
NULL
.
If the SoupContentSniffer feature is enabled, and the sniffer decided to perform sniffing, the first “got-chunk” emission may be delayed, so that the sniffer has enough data to correctly sniff the content. It notified the library user that the content has been sniffed, and allows it to change the header contents in the message, if desired.
After this signal is emitted, the data that was spooled so that sniffing could be done is delivered on the first emission of “got-chunk”.
Parameters
msg |
the message |
|
type |
the content type that we got from sniffing |
|
params |
a GHashTable with the parameters. |
[element-type utf8 utf8] |
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 2.28
The “finished”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted when all HTTP processing is finished for a message. (After “got_body” for client-side messages, or after “wrote_body” for server-side messages.)
Flags: Run First
The “got-body”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted after receiving the complete message body. (For a server-side message, this means it has received the request body. For a client-side message, this means it has received the response body and is nearly done with the message.)
See also soup_message_add_header_handler()
and
soup_message_add_status_code_handler()
, which can be used
to connect to a subset of emissions of this signal.
Flags: Run First
The “got-chunk”
signal
void user_function (SoupMessage *msg, SoupBuffer *chunk, gpointer user_data)
Emitted after receiving a chunk of a message body. Note that "chunk" in this context means any subpiece of the body, not necessarily the specific HTTP 1.1 chunks sent by the other side.
If you cancel or requeue msg
while processing this signal,
then the current HTTP I/O will be stopped after this signal
emission finished, and msg
's connection will be closed.
Parameters
msg |
the message |
|
chunk |
the just-read chunk |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
The “got-headers”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted after receiving all message headers for a message. (For a client-side message, this is after receiving the Status-Line and response headers; for a server-side message, it is after receiving the Request-Line and request headers.)
See also soup_message_add_header_handler()
and
soup_message_add_status_code_handler()
, which can be used
to connect to a subset of emissions of this signal.
If you cancel or requeue msg
while processing this signal,
then the current HTTP I/O will be stopped after this signal
emission finished, and msg
's connection will be closed.
(If you need to requeue a message--eg, after handling
authentication or redirection--it is usually better to
requeue it from a “got_body” handler rather
than a “got_headers” handler, so that the
existing HTTP connection can be reused.)
Flags: Run First
The “got-informational”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted after receiving a 1xx (Informational) response for a (client-side) message. The response_headers will be filled in with the headers associated with the informational response; however, those header values will be erased after this signal is done.
If you cancel or requeue msg
while processing this signal,
then the current HTTP I/O will be stopped after this signal
emission finished, and msg
's connection will be closed.
Flags: Run First
The “network-event”
signal
void user_function (SoupMessage *msg, GSocketClientEvent event, GIOStream *connection, gpointer user_data)
Emitted to indicate that some network-related event
related to msg
has occurred. This essentially proxies the
“event” signal, but only for events that
occur while msg
"owns" the connection; if msg
is sent on
an existing persistent connection, then this signal will
not be emitted. (If you want to force the message to be
sent on a new connection, set the
SOUP_MESSAGE_NEW_CONNECTION
flag on it.)
See “event” for more information on what
the different values of event
correspond to, and what
connection
will be in each case.
Parameters
msg |
the message |
|
event |
the network event |
|
connection |
the current state of the network connection |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 2.38
The “restarted”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted when a request that was already sent once is now being sent again (eg, because the first attempt received a redirection response, or because we needed to use authentication).
Flags: Run First
The “starting”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted just before a message is sent.
Flags: Run First
Since: 2.50
The “wrote-body”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted immediately after writing the complete body for a message. (For a client-side message, this means that libsoup is done writing and is now waiting for the response from the server. For a server-side message, this means that libsoup has finished writing the response and is nearly done with the message.)
Flags: Run First
The “wrote-body-data”
signal
void user_function (SoupMessage *msg, SoupBuffer *chunk, gpointer user_data)
Emitted immediately after writing a portion of the message body to the network.
Unlike “wrote_chunk”, this is emitted after
every successful write()
call, not only after finishing a
complete "chunk".
Parameters
msg |
the message |
|
chunk |
the data written |
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 2.24
The “wrote-chunk”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted immediately after writing a body chunk for a message.
Note that this signal is not parallel to
“got_chunk”; it is emitted only when a complete
chunk (added with soup_message_body_append()
or
soup_message_body_append_buffer()
) has been written. To get
more useful continuous progress information, use
“wrote_body_data”.
Flags: Run First
The “wrote-headers”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted immediately after writing the headers for a message. (For a client-side message, this is after writing the request headers; for a server-side message, it is after writing the response headers.)
Flags: Run First
The “wrote-informational”
signal
void user_function (SoupMessage *msg, gpointer user_data)
Emitted immediately after writing a 1xx (Informational) response for a (server-side) message.
Flags: Run First