## SoupMessage SoupMessage — An HTTP request and response. |

## Functions

SoupMessage * | soup_message_new ()
SoupMessage * | soup_message_new_from_uri ()
void | soup_message_set_request ()
void | soup_message_set_response ()
void | soup_message_set_http_version ()
SoupHTTPVersion | soup_message_get_http_version ()
SoupURI * | soup_message_get_uri ()
void | soup_message_set_uri ()
SoupAddress * | soup_message_get_address ()
void | soup_message_set_status ()
void | soup_message_set_status_full ()
void | soup_message_set_redirect ()
gboolean | soup_message_is_keepalive ()
gboolean | soup_message_get_https_status ()
void | soup_message_set_first_party ()
SoupURI * | soup_message_get_first_party ()
guint | soup_message_add_header_handler ()
guint | soup_message_add_status_code_handler ()
void | soup_message_set_flags ()
SoupMessageFlags | soup_message_get_flags ()
SoupBuffer * | (*SoupChunkAllocator) ()
void | soup_message_set_chunk_allocator ()
void | soup_message_disable_feature ()
SoupRequest * | soup_message_get_soup_request ()
SoupMessagePriority | soup_message_get_priority ()
void | soup_message_set_priority ()

## Properties

SoupURI * | first-party | Read / Write
SoupMessageFlags | flags | Read / Write
SoupHTTPVersion | http-version | 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
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

## Object Hierarchy

        GObject
        ╰── SoupMessage

## Includes

    #include <libsoup/soup.h>

## 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`

#### Parameters

method | the HTTP method for the created request |
uri_string | the destination endpoint (as a string) |

#### Returns

the new SoupMessage (or `NULL` if `uri` could not be parsed).

[nullable]

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

#### Returns

the new SoupMessage

### 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` |
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 `req_body` . |

### 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` |
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 `resp_body` . |

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

#### Parameters

msg | a SoupMessage |
version | the HTTP version |

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

#### Parameters

msg | a SoupMessage |

#### Returns

the HTTP version

### soup_message_get_uri ()

    SoupURI *
    soup_message_get_uri (SoupMessage *msg);

Gets `msg` 's URI

#### Parameters

msg | a SoupMessage |

#### Returns

the URI `msg` is targeted for.

[transfer none]

### 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()`.

#### Parameters

msg | a SoupMessage |
uri | the new SoupURI |

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

#### Parameters

msg | a SoupMessage |

#### Returns

the address `msg` 's URI points to.

[transfer none]

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.

#### Parameters

msg | a SoupMessage |
status_code | an HTTP status code |

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

#### Parameters

msg | a SoupMessage |
status_code | an HTTP status code |
reason_phrase | a description of the status |

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

#### Parameters

msg | a SoupMessage |
status_code | a 3xx status code |
redirect_uri | the URI to redirect `msg` to |

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.

#### Parameters

msg | a SoupMessage |

#### Returns

`TRUE` or `FALSE`.

### 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 | a SoupMessage |
certificate | `msg` 's TLS certificate. | [out][transfer none]
errors | the verification status of `certificate` . | [out]

#### Returns

`TRUE` if `msg` used/attempted https, `FALSE` if not

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.

#### Parameters

msg | a SoupMessage |
first_party | the SoupURI for the `msg` 's first party |

Since 2.30

### soup_message_get_first_party ()

    SoupURI *
    soup_message_get_first_party (SoupMessage *msg);

Gets `msg` 's first-party SoupURI

#### Parameters

msg | a SoupMessage |

#### Returns

the `msg` 's first party SoupURI.

[transfer none]

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

#### Parameters

msg | a SoupMessage |
signal | signal to connect the handler to. |
header | HTTP response header to match against |
callback | the header handler |
user_data | data to pass to `handler_cb` |

#### Returns

the handler ID from `g_signal_connect()`

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

#### Parameters

msg | a SoupMessage |
signal | signal to connect the handler to. |
status_code | status code to match against |
callback | the header handler |
user_data | data to pass to `handler_cb` |

#### Returns

the handler ID from `g_signal_connect()`

### soup_message_set_flags ()

    void
    soup_message_set_flags (SoupMessage *msg,
                            SoupMessageFlags flags);

Sets the specified flags on `msg` .

#### Parameters

msg | a SoupMessage |
flags | a set of SoupMessageFlags values |

### soup_message_get_flags ()

    SoupMessageFlags
    soup_message_get_flags (SoupMessage *msg);

Gets the flags on `msg`

#### Parameters

msg | a SoupMessage |

#### Returns

the flags

### 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_set_chunk_allocator()` |

#### Returns

the new buffer (or `NULL`).

[nullable]

### soup_message_set_chunk_allocator ()

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

`soup_message_set_chunk_allocator` is deprecated and should not be used in newly-written code.

SoupRequest provides a much simpler API that lets you read the response directly into your own buffers without needing to mess with callbacks, pausing/unpausing, etc.

Sets an alternate chunk-allocation function to use when reading `msg` 's body when using the traditional (ie, non-SoupRequest-based) API. 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.

#### Parameters

msg | a SoupMessage |
allocator | the chunk allocator callback |
user_data | data to pass to `allocator` |
destroy_notify | destroy notifier to free `user_data` when `msg` is destroyed |

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

#### Parameters

msg | a SoupMessage |
feature_type | the GType of a SoupSessionFeature |

Since 2.28

### 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`.

#### Parameters

msg | a SoupMessage |

#### Returns

`msg` 's associated SoupRequest.

[transfer none]

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.

#### Parameters

msg | a SoupMessage |

#### Returns

the priority of the message.

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.

#### Parameters

msg | a SoupMessage |
priority | the SoupMessagePriority |

Since 2.44

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

const char *`method`; | the HTTP method |
guint `status_code`; | the HTTP status code |
char *`reason_phrase`; | the status phrase associated with `status_code` |
SoupMessageBody *`request_body`; | the request body |
SoupMessageHeaders *`request_headers`; | the request headers |
SoupMessageBody *`response_body`; | the response body |
SoupMessageHeaders *`response_headers`; | the response headers |

### enum SoupHTTPVersion

Indicates the HTTP protocol version being used.

#### Members

SOUP_HTTP_1_0 | HTTP 1.0 (RFC 1945) |
SOUP_HTTP_1_1 | HTTP 1.1 (RFC 2616) |

### enum SoupMessageFlags

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

#### Members

SOUP_MESSAGE_NO_REDIRECT | The session should not follow redirect (3xx) responses received by this message. |
SOUP_MESSAGE_CAN_REBUILD | The caller will rebuild the request body if the message is restarted; see `soup_message_body_set_accumulate()` for more details. |
SOUP_MESSAGE_OVERWRITE_CHUNKS | Deprecated: equivalent to calling `soup_message_body_set_accumulate()` on the incoming message body (ie, “response_body” for a client-side request), passing `FALSE`. |
SOUP_MESSAGE_CONTENT_DECODED | 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). |
SOUP_MESSAGE_CERTIFICATE_TRUSTED | if set after an https response has been received, indicates that the server's SSL certificate is trusted according to the session's CA. |
SOUP_MESSAGE_NEW_CONNECTION | 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. |
SOUP_MESSAGE_IDEMPOTENT | 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. |
SOUP_MESSAGE_IGNORE_CONNECTION_LIMITS | 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 |

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

SOUP_MESSAGE_PRIORITY_VERY_LOW | The lowest priority, the messages with this priority will be the last ones to be attended. |
SOUP_MESSAGE_PRIORITY_LOW | Use this for low priority messages, a SoupMessage with the default priority will be processed first. |
SOUP_MESSAGE_PRIORITY_NORMAL | The default priotity, this is the priority assigned to the SoupMessage by default. |
SOUP_MESSAGE_PRIORITY_HIGH | High priority, a SoupMessage with this priority will be processed before the ones with the default priority. |
SOUP_MESSAGE_PRIORITY_VERY_HIGH | 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_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_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.

Flags: Read / Write

Since 2.30

### The `“flags”` property

      “flags”                    SoupMessageFlags

Various message options.

Flags: Read / Write

### The `“http-version”` property

      “http-version”             SoupHTTPVersion

The HTTP protocol version to use.

Flags: Read / Write

Default value: SOUP_HTTP_1_1

### The `“method”` property

      “method”                   gchar *

The message's HTTP method.

Flags: Read / Write

Default value: "GET"

### The `“priority”` property

      “priority”                 SoupMessagePriority

The priority of the message.

Flags: Read / Write

Default value: SOUP_MESSAGE_PRIORITY_NORMAL

### The `“reason-phrase”` property

      “reason-phrase”            gchar *

The HTTP response reason phrase.

Flags: Read / Write

Default value: NULL

### The `“request-body”` property

      “request-body”             SoupMessageBody *

The HTTP request content.

Flags: Read

### The `“request-body-data”` property

      “request-body-data”        GBytes *

The message's HTTP request body, as a GBytes.

Flags: Read

Since 2.46

### The `“request-headers”` property

      “request-headers”          SoupMessageHeaders *

The HTTP request headers.

Flags: Read

### The `“response-body”` property

      “response-body”            SoupMessageBody *

The HTTP response content.

Flags: Read

### The `“response-body-data”` property

      “response-body-data”       GBytes *

The message's HTTP response body, as a GBytes.

Flags: Read

Since 2.46

### The `“response-headers”` property

      “response-headers”         SoupMessageHeaders *

The HTTP response headers.

Flags: Read

### The `“server-side”` property

      “server-side”              gboolean

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

Flags: Read / Write / Construct Only

Default value: FALSE

### The `“status-code”` property

      “status-code”              guint

The HTTP response status code.

Flags: Read / Write

Allowed values: <= 599

Default value: 0

### The `“tls-certificate”` property

      “tls-certificate”          GTlsCertificate *

The GTlsCertificate associated with the message

Flags: Read / Write

Since 2.34

### The `“tls-errors”` property

      “tls-errors”               GTlsCertificateFlags

The verification errors on “tls-certificate”

Flags: Read / Write

Since 2.34

### The `“uri”` property

      “uri”                      SoupURI *

The message's Request-URI.

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

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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.

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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.

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

Flags: Run First

### The `“starting”` signal

    void
    user_function (SoupMessage *msg,
                   gpointer     user_data)

Emitted just before a message is sent.

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

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.

#### Parameters

msg | the message |
user_data | user data set when the signal handler was connected. |

Flags: Run First

## See Also

SoupMessageHeaders, SoupMessageBody