Class
SoupLogger
Description [src]
final class Soup.Logger : GObject.Object {
/* No available fields */
}Debug logging support
SoupLogger watches a SoupSession and logs the HTTP traffic that
it generates, for debugging purposes. Many applications use an
environment variable to determine whether or not to use
SoupLogger, and to determine the amount of debugging output.
To use SoupLogger, first create a logger with soup_logger_new(), optionally
configure it with soup_logger_set_request_filter(),
soup_logger_set_response_filter(), and soup_logger_set_printer(), and
then attach it to a session (or multiple sessions) with
soup_session_add_feature().
By default, the debugging output is sent to stdout, and looks something like:
> POST /unauth HTTP/1.1
> Soup-Debug-Timestamp: 1200171744
> Soup-Debug: SoupSession 1 (0x612190), SoupMessage 1 (0x617000), GSocket 1 (0x612220)
> Host: localhost
> Content-Type: text/plain
> Connection: close
< HTTP/1.1 201 Created
< Soup-Debug-Timestamp: 1200171744
< Soup-Debug: SoupMessage 1 (0x617000)
< Date: Sun, 12 Jan 2008 21:02:24 GMT
< Content-Length: 0
The Soup-Debug-Timestamp line gives the time (as a time_t) when the
request was sent, or the response fully received.
The Soup-Debug line gives further debugging information about the
SoupSession, SoupMessage, and GSocket involved; the hex
numbers are the addresses of the objects in question (which may be useful if
you are running in a debugger). The decimal IDs are simply counters that
uniquely identify objects across the lifetime of the SoupLogger. In
particular, this can be used to identify when multiple messages are sent
across the same connection.
Currently, the request half of the message is logged just before
the first byte of the request gets written to the network (from the
SoupMessage::starting signal).
The response is logged just after the last byte of the response body is read
from the network (from the SoupMessage::got-body or
SoupMessage::got-informational signal), which means that the
SoupMessage::got-headers signal, and anything triggered off it (such as
SoupMessage::authenticate) will be emitted before the response headers are
actually logged.
If the response doesn’t happen to trigger the SoupMessage::got-body nor
SoupMessage::got-informational signals due to, for example, a
cancellation before receiving the last byte of the response body, the
response will still be logged on the event of the SoupMessage::finished signal.
Instance methods
soup_logger_set_printer
Sets up an alternate log printing routine, if you don’t want
the log to go to stdout.
Properties
Soup.Logger:max-body-size
If SoupLogger:level is SOUP_LOGGER_LOG_BODY, this gives
the maximum number of bytes of the body that will be logged.
(-1 means “no limit”.)
Signals
Signals inherited from GObject (1)
GObject::notify
The 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.