GObject ╰── SoupLogger
SoupLogger implements SoupSessionFeature.
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
optionally configure it with
and then attach it to a session (or multiple sessions) with
By default, the debugging output is sent to
stdout, and looks something like:
> POST /unauth HTTP/1.1 > Soup-Debug-Timestamp: 1200171744 > Soup-Debug: SoupSessionAsync 1 (0x612190), SoupMessage 1 (0x617000), SoupSocket 1 (0x612220) > Host: localhost > Content-Type: text/plain > Connection: close > > This is a test. < 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
Soup-Debug-Timestamp line gives the time (as
a time_t) when the request was sent, or the response fully
Soup-Debug line gives further debugging
information about the SoupSession, SoupMessage, and SoupSocket
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
Currently, the request half of the message is logged just before the first byte of the request gets written to the network (from the “starting” signal), which means that if you have not made the complete request body available at that point, it will not be logged.
The response is logged just after the last byte of the response body is read from the network (from the “got_body” or “got_informational” signal), which means that the “got_headers” signal, and anything triggered off it (such as “authenticate”) will be emitted before the response headers are actually logged.
If the response doesn't happen to trigger the “got_body” nor “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 “finished” signal.
SoupLogger * soup_logger_new (
a new SoupLogger
SoupLoggerLogLevel (*SoupLoggerFilter) (
The prototype for a logging filter. The filter callback will be
invoked for each request or response, and should analyze it and
return a SoupLoggerLogLevel value indicating how much of the
message to log. Eg, it might choose between
SOUP_LOGGER_LOG_HEADERS depending on the Content-Type.
a SoupLoggerLogLevel value indicating how much of the message to log
void soup_logger_set_request_filter (
Sets up a filter to determine the log level for a given request.
For each HTTP request
determine how much (if any) of that request to log. (If you do not
set a request filter,
will just always log requests at the
level passed to
void soup_logger_set_response_filter (
Sets up a filter to determine the log level for a given response.
For each HTTP response
determine how much (if any) of that response to log. (If you do not
set a response filter,
will just always log responses at
the level passed to
void (*SoupLoggerPrinter) (
const char *data,
The prototype for a custom printing callback.
indicates what kind of information is being printed. Eg, it
is header data.
is either '<', '>', or ' ', and
is the single line
to print; the printer is expected to add a terminating newline.
To get the effect of the default printer, you would do:
printf ("%c %s\n", direction, data);
void soup_logger_set_printer (
Sets up an alternate log printing routine, if you don't want
the log to go to
Describes the level of logging output to provide.
The level of logging output
Flags: Read / Write
Default value: SOUP_LOGGER_LOG_MINIMAL