SignalRun Lastaccept-SignalRun LastauthenticateEmitted when the message requires authentication.
If credentials are available call Auth.authenticate on
auth. If these credentials fail, the signal will be emitted again,
with retrying set to true, which will continue until you return
without calling Auth.authenticate on auth.
Note that this may be emitted before msg's body has been
fully read.
You can authenticate auth asynchronously by calling
GObject.Object.ref on auth and returning true. The operation will
complete once either Auth.authenticate or
Auth.cancel are called.
SignalRun Firstcontent-This signal is emitted after Soup.Message::got-headers.
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
null.
SignalRun FirstfinishedEmitted when all HTTP processing is finished for a message.
(After Soup.Message::got_body).
SignalRun Firstgot-Emitted after receiving the complete message response body.
SignalRun Firstgot-Emitted after reading a portion of the message body from the network.
SignalRun Firstgot-Emitted after receiving the Status-Line and response headers.
See also Message.add_header_handler and 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 Soup.Message::got-body handler rather
than a Soup.Message::got_headers handler, so that the
existing HTTP connection can be reused.)
SignalRun Firstgot-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.
SignalRun Lasthsts-Emitted when HSTSEnforcer has upgraded the protocol
for msg to HTTPS as a result of matching its domain with
a HSTS policy.
SignalRun Firstnetwork-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.
SignalRun Lastrequest-Emitted during the msg's connection TLS handshake when
tls_connection requests a certificate from the client.
You can set the client certificate by calling
Message.set_tls_client_certificate and returning true. It's
possible to handle the request asynchornously by returning true and
call Message.set_tls_client_certificate later once the
certificate is available. Note that this signal is not emitted if
Session.tls_interaction was set, or if
Message.set_tls_client_certificate was called before the
connection TLS handshake started.
SignalRun Lastrequest-Emitted during the msg's connection TLS handshake when
tls_connection requests a certificate password from the client.
You can set the certificate password on password, then call
Message.tls_client_certificate_password_request_complete and
return true to handle the signal synchronously. It's possible to
handle the request asynchornously by calling
GObject.Object.ref on password, then returning true and
call
Message.tls_client_certificate_password_request_complete
later after setting the password on password. Note that this signal
is not emitted if Session.tls_interaction was set.
SignalRun FirstrestartedEmitted when a request that was already sent once is now being sent again.
e.g. because the first attempt received a redirection response, or because we needed to use authentication.
SignalRun FirststartingEmitted just before a message is sent.
SignalRun Firstwrote-Emitted immediately after writing the complete body for a message.
SignalRun Firstwrote-Emitted immediately after writing a portion of the message body to the network.
SignalRun Firstwrote-Emitted immediately after writing the request headers for a message.
SignalDetailedActionRun FirstnotifyThe notify signal is emitted on an object when one of its properties has
its value set through g_object_set_property(), g_object_set(), et al.
Note that getting this signal doesn’t itself guarantee that the value of
the property has actually changed. When it is emitted is determined by the
derived GObject class. If the implementor did not create the property with
GObject.ParamFlags.EXPLICIT_NOTIFY, then any call to g_object_set_property() results
in ::notify being emitted, even if the new value is the same as the old.
If they did pass GObject.ParamFlags.EXPLICIT_NOTIFY, then this signal is emitted only
when they explicitly call g_object_notify() or g_object_notify_by_pspec(),
and common practice is to do that only when the value has actually changed.
This signal is typically used to obtain change notification for a
single property, by specifying the property name as a detail in the
g_signal_connect() call, like this:
g_signal_connect (text_view->buffer, "notify::paste-target-list",
G_CALLBACK (gtk_text_view_target_list_notify),
text_view)
It is important to note that you must use [canonical parameter names][class@GObject.ParamSpec#parameter-names] as detail strings for the notify signal.
Emitted during the
msg's connection TLS handshake after an unacceptable TLS certificate has been received.You can return
trueto accepttls_certificatedespitetls_errors.