Debug logging support
Logger watches a [class@Session] and logs the HTTP traffic that it generates, for debugging purposes. Many
applications use an environment variable to determine whether or not to use Logger, and to determine the amount
of debugging output.
To use Logger, first create a logger with [[email protected]], optionally configure it with [
[email protected]_request_filter], [[email protected]_response_filter], and [[email protected]_printer], and then attach it to a session (
or multiple sessions) with [[email protected]_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 [class@Session], [class@Message], and [[email protected]] 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 Logger. 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 [
signal@Message:SoupLogger:starting] signal).
The response is logged just after the last byte of the response body is read from the network (from the [signal@Message:
SoupLogger:got-body] or [signal@Message:SoupLogger:got-informational] signal), which means that the [signal@Message:
SoupLogger:got-headerss] 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 [signal@Message:SoupLogger:got-body] nor [signal@Message:
SoupLogger: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 [signal@Message:SoupLogger:finished] signal.