Soup.Message¶

Subclasses:: None

Methods¶

Inherited:: GObject.Object (37)
Structs:: GObject.ObjectClass (5)

class	`new` (method, uri_string)
class	`new_from_uri` (method, uri)
	`content_sniffed` (content_type, params)
	`disable_feature` (feature_type)
	`finished` ()
	`get_address` ()
	`get_first_party` ()
	`get_flags` ()
	`get_http_version` ()
	`get_https_status` ()
	`get_is_top_level_navigation` ()
	`get_priority` ()
	`get_site_for_cookies` ()
	`get_soup_request` ()
	`get_uri` ()
	`got_body` ()
	`got_chunk` (chunk)
	`got_headers` ()
	`got_informational` ()
	`is_feature_disabled` (feature_type)
	`is_keepalive` ()
	`restarted` ()
	`set_chunk_allocator` (allocator, *user_data)
	`set_first_party` (first_party)
	`set_flags` (flags)
	`set_http_version` (version)
	`set_is_top_level_navigation` (is_top_level_navigation)
	`set_priority` (priority)
	`set_redirect` (status_code, redirect_uri)
	`set_request` (content_type, req_use, req_body)
	`set_response` (content_type, resp_use, resp_body)
	`set_site_for_cookies` (site_for_cookies)
	`set_status` (status_code)
	`set_status_full` (status_code, reason_phrase)
	`set_uri` (uri)
	`starting` ()
	`wrote_body` ()
	`wrote_body_data` (chunk)
	`wrote_chunk` ()
	`wrote_headers` ()
	`wrote_informational` ()

Virtual Methods¶

Inherited:: GObject.Object (7)

	`do_finished` ()
	`do_got_body` ()
	`do_got_chunk` (chunk)
	`do_got_headers` ()
	`do_got_informational` ()
	`do_restarted` ()
	`do_starting` ()
	`do_wrote_body` ()
	`do_wrote_chunk` ()
	`do_wrote_headers` ()
	`do_wrote_informational` ()

Properties¶

Name	Type	Flags	Short Description
`first-party`	`Soup.URI`	r/w	The URI loaded in the application when the message was requested.
`flags`	`Soup.MessageFlags`	r/w	Various message options
`http-version`	`Soup.HTTPVersion`	r/w	The HTTP protocol version to use
`is-top-level-navigation`	`bool`	r/w	If the current messsage is navigating between top-levels
`method`	`str`	r/w	The message’s HTTP method
`priority`	`Soup.MessagePriority`	r/w	The priority of the message
`reason-phrase`	`str`	r/w	The HTTP response reason phrase
`request-body`	`Soup.MessageBody`	r	The HTTP request content
`request-body-data`	`GLib.Bytes`	r	The HTTP request body
`request-headers`	`Soup.MessageHeaders`	r	The HTTP request headers
`response-body`	`Soup.MessageBody`	r	The HTTP response content
`response-body-data`	`GLib.Bytes`	r	The HTTP response body
`response-headers`	`Soup.MessageHeaders`	r	The HTTP response headers
`server-side`	`bool`	r/w/co	Whether or not the message is server-side rather than client-side
`site-for-cookies`	`Soup.URI`	r/w	The URI for the site to compare cookies against
`status-code`	`int`	r/w	The HTTP response status code
`tls-certificate`	`Gio.TlsCertificate`	r/w	The TLS certificate associated with the message
`tls-errors`	`Gio.TlsCertificateFlags`	r/w	The verification errors on the message’s TLS certificate
`uri`	`Soup.URI`	r/w	The message’s Request-URI

Signals¶

Inherited:: GObject.Object (1)

Name	Short Description
`content-sniffed`	This signal is emitted after `Soup.Message` `::got-headers`, and before the first `Soup.Message` `::got-chunk`.
`finished`	Emitted when all HTTP processing is finished for a message.
`got-body`	Emitted after receiving the complete message body.
`got-chunk`	Emitted after receiving a chunk of a message body.
`got-headers`	Emitted after receiving all message headers for a message.
`got-informational`	Emitted after receiving a 1xx (Informational) response for a (client-side) message.
`network-event`	Emitted to indicate that some network-related event related to msg has occurred.
`restarted`	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).
`starting`	Emitted just before a message is sent.
`wrote-body`	Emitted immediately after writing the complete body for a message.
`wrote-body-data`	Emitted immediately after writing a portion of the message body to the network.
`wrote-chunk`	Emitted immediately after writing a body chunk for a message.
`wrote-headers`	Emitted immediately after writing the headers for a message.
`wrote-informational`	Emitted immediately after writing a 1xx (Informational) response for a (server-side) message.

Fields¶

Inherited:: GObject.Object (1)

Name	Type	Access	Description
method	`str`	r	the HTTP method
parent	`GObject.Object`	r
reason_phrase	`str`	r	the status phrase associated with status_code
request_body	`Soup.MessageBody`	r	the request body
request_headers	`Soup.MessageHeaders`	r	the request headers
response_body	`Soup.MessageBody`	r	the response body
response_headers	`Soup.MessageHeaders`	r	the response headers
status_code	`int`	r	the HTTP status code

Class Details¶

class Soup.Message(**kwargs)¶

Bases:: GObject.Object
Abstract:: No
Structure:: Soup.MessageClass

Represents an HTTP message being sent or received.

status_code will normally be a Soup.Status 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 Soup.MessageBody 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 Soup.Message, 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.MessageBody.flatten() if you want to ensure that data is filled in. If you are not using Soup.Request to read the response, then response_body's data will be filled in before Soup.Message ::finished is emitted. (If you are using Soup.Request, then the message body is not accumulated by default, so response_body's data will always be None.)

For a server-side Soup.Message, request_body's %data will be filled in before #SoupMessage::got_body is emitted.

To prevent the %data field from being filled in at all (eg, if you are handling the data from a #SoupMessage::got_chunk, and so don’t need to see it all at the end), call Soup.MessageBody.set_accumulate() on response_body or request_body as appropriate, passing False.

classmethod new(method, uri_string)¶

Parameters:

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

Returns:

the new Soup.Message (or None if uri could not be parsed).

Return type:

Soup.Message or None

Creates a new empty Soup.Message, which will connect to uri

classmethod new_from_uri(method, uri)¶

Parameters:

method (str) – the HTTP method for the created request
uri (Soup.URI) – the destination endpoint (as a Soup.URI)

Returns:

the new Soup.Message

Return type:

Soup.Message

Creates a new empty Soup.Message, which will connect to uri

content_sniffed(content_type, params)¶

Parameters:

content_type (str) –
params ({object: object}) –

disable_feature(feature_type)¶

Parameters:: feature_type (GObject.GType) – the GObject.GType of a Soup.SessionFeature

This disables the actions of Soup.SessionFeature s with the given feature_type (or a subclass of that type) on self, so that self 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 self 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.

New in version 2.28.

finished()¶

get_address()¶

Returns:: the address self's URI points to
Return type:: Soup.Address

Gets the address self'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.

New in version 2.26.

get_first_party()¶

Returns:: the self's first party Soup.URI
Return type:: Soup.URI

Gets self's first-party Soup.URI

New in version 2.30.

get_flags()¶

Returns:: the flags
Return type:: Soup.MessageFlags

Gets the flags on self

get_http_version()¶

Returns:: the HTTP version
Return type:: Soup.HTTPVersion

Gets the HTTP version of self. This is the minimum of the version from the request and the version from the response.

get_https_status()¶

Returns:

True if self used/attempted https, False if not

certificate:: self's TLS certificate
errors:: the verification status of certificate

Return type:

(bool, certificate: Gio.TlsCertificate, errors: Gio.TlsCertificateFlags)

If self is using https (or attempted to use https but got Soup.Status.SSL_FAILED), this retrieves the Gio.TlsCertificate associated with its connection, and the Gio.TlsCertificateFlags showing what problems, if any, have been found with that certificate.

This is only meaningful with messages processed by a Soup.Session and is not useful for messages received by a Soup.Server

New in version 2.34.

get_is_top_level_navigation()¶

Return type:: bool

New in version 2.70.

get_priority()¶

Returns:: the priority of the message.
Return type:: Soup.MessagePriority

Retrieves the Soup.MessagePriority. If not set this value defaults to Soup.MessagePriority.NORMAL.

New in version 2.44.

get_site_for_cookies()¶

Returns:: the self's site for cookies Soup.URI
Return type:: Soup.URI

Gets self's site for cookies Soup.URI

New in version 2.70.

get_soup_request()¶

Returns:: self's associated Soup.Request
Return type:: Soup.Request

If self is associated with a Soup.Request, this returns that request. Otherwise it returns None.

New in version 2.42.

get_uri()¶

Returns:: the URI self is targeted for.
Return type:: Soup.URI

Gets self's URI

got_body()¶

got_chunk(chunk)¶

Parameters:: chunk (Soup.Buffer) –

got_headers()¶

got_informational()¶

is_feature_disabled(feature_type)¶

Parameters:: feature_type (GObject.GType) – the GObject.GType of a Soup.SessionFeature
Returns:: True if feature is disabled, or False otherwise.
Return type:: bool

Get whether Soup.SessionFeature s of the given feature_type (or a subclass of that type) are disabled on self. See Soup.Message.disable_feature().

New in version 2.72.

is_keepalive()¶

Returns:: True or False.
Return type:: bool

Determines whether or not self's connection can be kept alive for further requests after processing self, based on the HTTP version, Connection header, etc.

restarted()¶

set_chunk_allocator(allocator, *user_data)¶

Parameters:

allocator (Soup.ChunkAllocator) – the chunk allocator callback
user_data (object or None) – data to pass to allocator

Sets an alternate chunk-allocation function to use when reading self's body when using the traditional (ie, non-Soup.Request -based) API. Every time data is available to read, libsoup will call allocator, which should return a Soup.Buffer. (See Soup.ChunkAllocator 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.MessageBody.set_accumulate() False and #SoupMessage::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 #SoupMessage::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 #SoupMessage::got_chunk handler.

The other thing to remember when using non-accumulating message bodies is that the buffer passed to the #SoupMessage::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 Soup.Buffer (or its owner, in the Soup.Buffer.new_with_owner() case) to ensure that the data remains valid.

Deprecated since version ???: Soup.Request 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.

set_first_party(first_party)¶

Parameters:: first_party (Soup.URI) – the Soup.URI for the self's first party

Sets first_party as the main document Soup.URI for self. For details of when and how this is used refer to the documentation for Soup.CookieJarAcceptPolicy.

New in version 2.30.

set_flags(flags)¶

Parameters:: flags (Soup.MessageFlags) – a set of Soup.MessageFlags values

Sets the specified flags on self.

set_http_version(version)¶

Parameters:: version (Soup.HTTPVersion) – the HTTP version

Sets the HTTP version on self. The default version is Soup.HTTPVersion.HTTP_1_1. Setting it to Soup.HTTPVersion.HTTP_1_0 will prevent certain functionality from being used.

set_is_top_level_navigation(is_top_level_navigation)¶

Parameters:: is_top_level_navigation (bool) – if True indicate the current request is a top-level navigation

See the same-site spec for more information.

New in version 2.70.

set_priority(priority)¶

Parameters:: priority (Soup.MessagePriority) – the Soup.MessagePriority

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 Soup.SessionSync (or with synchronous messages on a plain Soup.Session) because in the synchronous/blocking case, priority ends up being determined semi-randomly by thread scheduling.

New in version 2.44.

set_redirect(status_code, redirect_uri)¶

Parameters:

status_code (int) – a 3xx status code
redirect_uri (str) – the URI to redirect self to

Sets self's status_code to status_code and adds a Location header pointing to redirect_uri. Use this from a Soup.Server 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 self's current URI. In particular, if redirect_uri is just a path, it will replace the path and query of self's URI.

New in version 2.38.

set_request(content_type, req_use, req_body)¶

Parameters:

content_type (str or None) – MIME Content-Type of the body
req_use (Soup.MemoryUse) – a Soup.MemoryUse describing how to handle req_body
req_body (bytes or None) – a data buffer containing the body of the message request.

Convenience function to set the request body of a Soup.Message. If content_type is None, the request body must be empty as well.

set_response(content_type, resp_use, resp_body)¶

Parameters:

content_type (str or None) – MIME Content-Type of the body
resp_use (Soup.MemoryUse) – a Soup.MemoryUse describing how to handle resp_body
resp_body (bytes or None) – a data buffer containing the body of the message response.

Convenience function to set the response body of a Soup.Message. If content_type is None, the response body must be empty as well.

set_site_for_cookies(site_for_cookies)¶

Parameters:: site_for_cookies (Soup.URI or None) – the Soup.URI for the self's site for cookies

Sets site_for_cookies as the policy URL for same-site cookies for self.

It is either the URL of the top-level document or None 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.

New in version 2.70.

set_status(status_code)¶

Parameters:: status_code (int) – an HTTP status code

Sets self's status code to status_code. If status_code is a known value, it will also set self's reason_phrase.

set_status_full(status_code, reason_phrase)¶

Parameters:

status_code (int) – an HTTP status code
reason_phrase (str) – a description of the status

Sets self's status code and reason phrase.

set_uri(uri)¶

Parameters:: uri (Soup.URI) – the new Soup.URI

Sets self's URI to uri. If self has already been sent and you want to re-send it with the new URI, you need to call Soup.Session.requeue_message().

starting()¶

wrote_body()¶

wrote_body_data(chunk)¶

Parameters:: chunk (Soup.Buffer) –

wrote_chunk()¶

wrote_headers()¶

wrote_informational()¶

do_finished() virtual¶

do_got_body() virtual¶

do_got_chunk(chunk) virtual¶

Parameters:: chunk (Soup.Buffer) –

do_got_headers() virtual¶

do_got_informational() virtual¶

do_restarted() virtual¶

do_starting() virtual¶

do_wrote_body() virtual¶

do_wrote_chunk() virtual¶

do_wrote_headers() virtual¶

do_wrote_informational() virtual¶

Signal Details¶

Soup.Message.signals.content_sniffed(message, type, params)¶

Signal Name:

content-sniffed

Flags:

RUN_FIRST

Parameters:

message (Soup.Message) – The object which received the signal
type (str) – the content type that we got from sniffing
params ({str: str}) – a GLib.HashTable with the parameters

This signal is emitted after Soup.Message ::got-headers, and before the first Soup.Message ::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 Soup.Message ::got-headers, and type is None.

If the Soup.ContentSniffer feature is enabled, and the sniffer decided to perform sniffing, the first Soup.Message ::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 Soup.Message ::got-chunk.

New in version 2.28.

Soup.Message.signals.finished(message)¶

Signal Name:: finished
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

Emitted when all HTTP processing is finished for a message. (After #SoupMessage::got_body for client-side messages, or after #SoupMessage::wrote_body for server-side messages.)

Soup.Message.signals.got_body(message)¶

Signal Name:: got-body
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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.

Soup.Message.signals.got_chunk(message, chunk)¶

Signal Name:

got-chunk

Flags:

RUN_FIRST

Parameters:

message (Soup.Message) – The object which received the signal
chunk (Soup.Buffer) – the just-read chunk

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.

Soup.Message.signals.got_headers(message)¶

Signal Name:: got-headers
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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 #SoupMessage::got_body handler rather than a #SoupMessage::got_headers handler, so that the existing HTTP connection can be reused.)

Soup.Message.signals.got_informational(message)¶

Signal Name:: got-informational
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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.

Soup.Message.signals.network_event(message, event, connection)¶

Signal Name:

network-event

Flags:

RUN_FIRST

Parameters:

message (Soup.Message) – The object which received the signal
event (Gio.SocketClientEvent) – the network event
connection (Gio.IOStream) – the current state of the network connection

Emitted to indicate that some network-related event related to msg has occurred. This essentially proxies the Gio.SocketClient ::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.MessageFlags.NEW_CONNECTION flag on it.)

See Gio.SocketClient ::event for more information on what the different values of event correspond to, and what connection will be in each case.

New in version 2.38.

Soup.Message.signals.restarted(message)¶

Signal Name:: restarted
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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

Soup.Message.signals.starting(message)¶

Signal Name:: starting
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

Emitted just before a message is sent.

New in version 2.50.

Soup.Message.signals.wrote_body(message)¶

Signal Name:: wrote-body
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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

Soup.Message.signals.wrote_body_data(message, chunk)¶

Signal Name:

wrote-body-data

Flags:

RUN_FIRST

Parameters:

message (Soup.Message) – The object which received the signal
chunk (Soup.Buffer) – the data written

Emitted immediately after writing a portion of the message body to the network.

Unlike #SoupMessage::wrote_chunk, this is emitted after every successful write() call, not only after finishing a complete “chunk”.

New in version 2.24.

Soup.Message.signals.wrote_chunk(message)¶

Signal Name:: wrote-chunk
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

Emitted immediately after writing a body chunk for a message.

Note that this signal is not parallel to #SoupMessage::got_chunk; it is emitted only when a complete chunk (added with Soup.MessageBody.append() or Soup.MessageBody.append_buffer()) has been written. To get more useful continuous progress information, use #SoupMessage::wrote_body_data.

Soup.Message.signals.wrote_headers(message)¶

Signal Name:: wrote-headers
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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

Soup.Message.signals.wrote_informational(message)¶

Signal Name:: wrote-informational
Flags:: RUN_FIRST
Parameters:: message (Soup.Message) – The object which received the signal

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

Property Details¶

Soup.Message.props.first_party¶

Name:: first-party
Type:: Soup.URI
Default Value:: None
Flags:: READABLE, WRITABLE

The Soup.URI loaded in the application when the message was queued.

New in version 2.30.

Soup.Message.props.flags¶

Name:: flags
Type:: Soup.MessageFlags
Default Value:: 0
Flags:: READABLE, WRITABLE

Various message options

Soup.Message.props.http_version¶

Name:: http-version
Type:: Soup.HTTPVersion
Default Value:: Soup.HTTPVersion.HTTP_1_1
Flags:: READABLE, WRITABLE

The HTTP protocol version to use

Soup.Message.props.is_top_level_navigation¶

Name:: is-top-level-navigation
Type:: bool
Default Value:: False
Flags:: READABLE, WRITABLE

Set when the message is navigating between top level domains.

New in version 2.70.

Soup.Message.props.method¶

Name:: method
Type:: str
Default Value:: 'GET'
Flags:: READABLE, WRITABLE

The message’s HTTP method

Soup.Message.props.priority¶

Name:: priority
Type:: Soup.MessagePriority
Default Value:: Soup.MessagePriority.NORMAL
Flags:: READABLE, WRITABLE

The priority of the message

Soup.Message.props.reason_phrase¶

Name:: reason-phrase
Type:: str
Default Value:: None
Flags:: READABLE, WRITABLE

The HTTP response reason phrase

Soup.Message.props.request_body¶

Name:: request-body
Type:: Soup.MessageBody
Default Value:: None
Flags:: READABLE

The HTTP request content

Soup.Message.props.request_body_data¶

Name:: request-body-data
Type:: GLib.Bytes
Default Value:: None
Flags:: READABLE

The message’s HTTP request body, as a GLib.Bytes.

New in version 2.46.

Soup.Message.props.request_headers¶

Name:: request-headers
Type:: Soup.MessageHeaders
Default Value:: None
Flags:: READABLE

The HTTP request headers

Soup.Message.props.response_body¶

Name:: response-body
Type:: Soup.MessageBody
Default Value:: None
Flags:: READABLE

The HTTP response content

Soup.Message.props.response_body_data¶

Name:: response-body-data
Type:: GLib.Bytes
Default Value:: None
Flags:: READABLE

The message’s HTTP response body, as a GLib.Bytes.

New in version 2.46.

Soup.Message.props.response_headers¶

Name:: response-headers
Type:: Soup.MessageHeaders
Default Value:: None
Flags:: READABLE

The HTTP response headers

Soup.Message.props.server_side¶

Name:: server-side
Type:: bool
Default Value:: False
Flags:: READABLE, WRITABLE, CONSTRUCT_ONLY

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

Soup.Message.props.site_for_cookies¶

Name:: site-for-cookies
Type:: Soup.URI
Default Value:: None
Flags:: READABLE, WRITABLE

The URI for the site to compare cookies against

Soup.Message.props.status_code¶

Name:: status-code
Type:: int
Default Value:: 0
Flags:: READABLE, WRITABLE

The HTTP response status code

Soup.Message.props.tls_certificate¶

Name:: tls-certificate
Type:: Gio.TlsCertificate
Default Value:: None
Flags:: READABLE, WRITABLE

The Gio.TlsCertificate associated with the message

New in version 2.34.

Soup.Message.props.tls_errors¶

Name:: tls-errors
Type:: Gio.TlsCertificateFlags
Default Value:: Gio.TlsCertificateFlags.NO_FLAGS
Flags:: READABLE, WRITABLE

The verification errors on Soup.Message :tls-certificate

New in version 2.34.

Soup.Message.props.uri¶

Name:: uri
Type:: Soup.URI
Default Value:: None
Flags:: READABLE, WRITABLE

The message’s Request-URI