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 SoupKnownStatusCode, 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 they 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. response_body's data will be filled in before "finished" is emitted.

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.

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

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.

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.

enum SoupHTTPVersion

typedef enum {
	SOUP_HTTP_1_0 = 0, /*< nick=http-1-0 >*/
	SOUP_HTTP_1_1 = 1  /*< nick=http-1-1 >*/
} SoupHTTPVersion;

Indicates the HTTP protocol version being used.

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_get_uri ()

SoupURI *           soup_message_get_uri                (SoupMessage *msg);

Gets msg's URI

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, this retrieves the GTlsCertificate associated with its connection, and the GTlsCertificateFlags showing what problems, if any, have been found with that certificate.

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 with two differences: the callback will only be run if msg has a header named header, and it will only be run if no earlier handler cancelled or requeued the message.

If signal is one of the "got" signals (eg, "got_headers"), or "finished" or "restarted", then header is matched against the incoming message headers (that is, the request_headers for a client SoupMessage, or the response_headers for a server SoupMessage). If signal is one of the "wrote" signals, then header is matched against the outgoing message headers.

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 with two differences: the callback will only be run if msg has the status status_code, and it will only be run if no earlier handler cancelled or requeued the message.

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.

enum SoupMessageFlags

typedef enum {
	SOUP_MESSAGE_NO_REDIRECT          = (1 << 1),
	SOUP_MESSAGE_CAN_REBUILD          = (1 << 2),
#ifndef LIBSOUP_DISABLE_DEPRECATED
	SOUP_MESSAGE_OVERWRITE_CHUNKS     = (1 << 3),
#endif
	SOUP_MESSAGE_CONTENT_DECODED      = (1 << 4),
	SOUP_MESSAGE_CERTIFICATE_TRUSTED  = (1 << 5),
	SOUP_MESSAGE_NEW_CONNECTION       = (1 << 6)
} SoupMessageFlags;

Various flags that can be set on a SoupMessage to alter its behavior.

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);

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.

soup_message_set_chunk_allocator ()

void                soup_message_set_chunk_allocator    (SoupMessage *msg,
                                                         SoupChunkAllocator allocator,
                                                         gpointer user_data,
                                                         GDestroyNotify destroy_notify);

Sets an alternate chunk-allocation function to use when reading msg's body. Every time data is available to read, libsoup will call allocator, which should return a SoupBuffer. (See SoupChunkAllocator for additional details.) Libsoup will then read data from the network into that buffer, and update the buffer's length to indicate how much data it read.

Generally, a custom chunk allocator would be used in conjunction with soup_message_body_set_accumulate() FALSE and "got_chunk", as part of a strategy to avoid unnecessary copying of data. However, you cannot assume that every call to the allocator will be followed by a call to your "got_chunk" handler; if an I/O error occurs, then the buffer will be unreffed without ever having been used. If your buffer-allocation strategy requires special cleanup, use soup_buffer_new_with_owner() rather than doing the cleanup from the "got_chunk" handler.

The other thing to remember when using non-accumulating message bodies is that the buffer passed to the "got_chunk" handler will be unreffed after the handler returns, just as it would be in the non-custom-allocated case. If you want to hand the chunk data off to some other part of your program to use later, you'll need to ref the SoupBuffer (or its owner, in the soup_buffer_new_with_owner() case) to ensure that the data remains valid.

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_PROXY_URI_RESOLVER for feature_type will disable proxy handling and cause msg to be sent directly to the indicated origin server, regardless of system proxy configuration.

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_METHOD

#define SOUP_MESSAGE_METHOD           "method"

Alias for the "method" property. (The message's HTTP method.)

SOUP_MESSAGE_URI

#define SOUP_MESSAGE_URI              "uri"

Alias for the "uri" property. (The message's SoupURI.)

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_REQUEST_BODY

#define SOUP_MESSAGE_REQUEST_BODY     "request-body"

Alias for the "request-body" property. (The message's HTTP request body.)

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_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

The "first-party" property

  "first-party"              SoupURI*              : Read / Write

The SoupURI loaded in the application when the message was queued.

Since 2.30

The "flags" property

  "flags"                    SoupMessageFlags      : Read / Write

Various message options.

The "http-version" property

  "http-version"             SoupHTTPVersion       : Read / Write

The HTTP protocol version to use.

Default value: SOUP_HTTP_1_1

The "method" property

  "method"                   gchar*                : Read / Write

The message's HTTP method.

Default value: "GET"

The "reason-phrase" property

  "reason-phrase"            gchar*                : Read / Write

The HTTP response reason phrase.

Default value: NULL

The "request-body" property

  "request-body"             SoupMessageBody*      : Read

The HTTP request content.

The "request-headers" property

  "request-headers"          SoupMessageHeaders*   : Read

The HTTP request headers.

The "response-body" property

  "response-body"            SoupMessageBody*      : Read

The HTTP response content.

The "response-headers" property

  "response-headers"         SoupMessageHeaders*   : Read

The HTTP response headers.

The "server-side" property

  "server-side"              gboolean              : Read / Write / Construct Only

Whether or not the message is server-side rather than client-side.

Default value: FALSE

The "status-code" property

  "status-code"              guint                 : Read / Write

The HTTP response status code.

Allowed values: <= 599

Default value: 0

The "tls-certificate" property

  "tls-certificate"          GTlsCertificate*      : Read / Write

The GTlsCertificate associated with the message

Since 2.34

The "tls-errors" property

  "tls-errors"               GTlsCertificateFlags  : Read / Write

The verification errors on "tls-certificate"

Since 2.34

The "uri" property

  "uri"                      SoupURI*              : Read / Write

The message's Request-URI.

The "content-sniffed" signal

void                user_function                      (SoupMessage *msg,
                                                        gchar       *type,
                                                        GHashTable  *params,
                                                        gpointer     user_data)      : Run First

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".

Since 2.27.3

The "finished" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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.)

The "got-body" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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.

The "got-chunk" signal

void                user_function                      (SoupMessage *msg,
                                                        SoupBuffer  *chunk,
                                                        gpointer     user_data)      : Run First

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.

The "got-headers" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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.)

The "got-informational" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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.

The "network-event" signal

void                user_function                      (SoupMessage       *msg,
                                                        GSocketClientEvent event,
                                                        GIOStream         *connection,
                                                        gpointer           user_data)       : Run First

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.

Since 2.38

The "restarted" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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).

The "wrote-body" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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.)

The "wrote-body-data" signal

void                user_function                      (SoupMessage *msg,
                                                        SoupBuffer  *chunk,
                                                        gpointer     user_data)      : Run First

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".

Since 2.4.1

The "wrote-chunk" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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".

The "wrote-headers" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

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.)

The "wrote-informational" signal

void                user_function                      (SoupMessage *msg,
                                                        gpointer     user_data)      : Run First

Emitted immediately after writing a 1xx (Informational) response for a (server-side) message.