Logger

Debug logging support

#SoupLogger 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 #SoupLogger, and to determine the amount of debugging output.

To use #SoupLogger, first create a logger with ctor@Logger.new, optionally configure it with method@Logger.set_request_filter, method@Logger.set_response_filter, and method@Logger.set_printer, and then attach it to a session (or multiple sessions) with method@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 class@Session, class@Message, and class@Gio.Socket 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 signal@Message::starting signal).

The response is logged just after the last byte of the response body is read from the network (from the signal@Message::got-body or signal@Message::got-informational signal), which means that the signal@Message::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 signal@Message::got-body nor signal@Message::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::finished signal.

Skipped during bindings generation

• method level: Property has no getter nor setter