Re: access log

["J. David Ibáñez" <jdavid itaapy com>]

Tried with the master branch of libsoup and got the same results. Put
a printf in libsoup's "request_finished" and the "client" variable is
right.

I am using hooks actually, this is the register call:

  signal_id = g_signal_lookup ("request-finished", SOUP_TYPE_SERVER);
  g_signal_add_emission_hook (signal_id, 0, log_access, self, NULL);

Then in the callback I get the arguments this way:

  static gboolean
  log_access (GSignalInvocationHint *ihint, guint n_param_values,

              const GValue *param_values, gpointer data)

  {
    [...]
    printf("n_param_values is %d\n", n_param_values);
    s_server = (SoupServer*) g_value_get_object (param_values);
    s_msg = (SoupMessage*) g_value_get_object (++param_values);
    s_client = (SoupClientContext*) g_value_get_object (++param_values);
    if (s_client == NULL)
      printf("s_client is NULL\n");

This is the output:

  n_param_values is 3
  [...]: Warning: g_value_get_object: assertion `G_VALUE_HOLDS_OBJECT
(value)' failed
  [...]
  s_client is NULL

Both s_server and s_msg are right, only the s_client is wrong.

I tried with glib 2.18.4 and 2.20.4



Dan Winship wrote:
> On 08/05/2009 10:03 AM, "J. David Ibáñez" wrote:
>> The 'request-finished' signal in particular, which in theory gives
>> the required information: the message and the client context.  The
>> problem is the client context is always NULL, so I cannot get the
>> client address.
> 
> Hm? That can't be right. soup-server.c does:
> 
> 	SoupServer *server = client->server;
> 	SoupSocket *sock = client->sock;
> 
> 	g_signal_emit (server,
> 		       msg->status_code == SOUP_STATUS_IO_ERROR ?
> 		       signals[REQUEST_ABORTED] : signals[REQUEST_FINISHED],
> 		       0, msg, client);
> 
> So if client was NULL it would crash before emitting the signal.
> 
> Are you sure you've got the signal handler arguments right?
> 
>> Is this a bug? Is there a better way to implement an access log?
> 
> request-finished sounds right to me. (Though, as pointed out by the code
> quoted above, you'll need to catch request-aborted too if you want to
> log requests where the client disconnects part-way through.)
> 
> FWIW, I've just pushed a "server-feature" branch to libsoup git, which
> adds SoupServerFeature along the lines of SoupSessionFeature, and adds
> support to SoupLogger for logging server-side requests as well. But it
> does it by connecting to request-started, and then watching SoupMessage
> signals from that point. But connecting to request-finished *should* work...
> 
> -- Dan


-- 
J. David Ibáñez
Itaapy <http://www.itaapy.com>         Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris              Fax +33 (0)1 53 28 27 88