Re: Implementing Navigation Timing in WebKit using libsoup
- From: Dan Winship <danw gnome org>
- To: Zan Dobersek <zandobersek gmail com>
- Cc: libsoup-list gnome org
- Subject: Re: Implementing Navigation Timing in WebKit using libsoup
- Date: Thu, 24 Feb 2011 14:20:43 -0500
On 02/23/2011 04:25 PM, Zan Dobersek wrote:
> In WebKit, the document loading infrastructure takes care of setting
> most of attributes to current time except the following:
> domainLookupStart
> domainLookupEnd
> connectStart
> connectEnd
> secureConnectionStart
> requestStart
> responseStart
...
> My question is, how would one acquire the time of other events -
> connectStart, connectEnd, secureConnectionStart and perhaps even the
> domainLookup* attributes, if it ever comes to performing domain lookup?
requestStart probably corresponds to the SoupSession "request-started"
signal (which is emitted just before writing the first byte of the
request to the connection). responseStart would probably correspond to
the "got-headers" signal on the SoupMessage (which would be emitted
after libsoup had received the HTTP headers of the response, but before
it received the body).
The other information you can get via semi-private APIs; SoupSession
will emit "connection-created" whenever it creates a new connection
object, and then you can connect to "notify::state" on the connection to
see the connection's state, which will take values from the
SoupConnectionState enumeration in soup-misc.h. connectStart would be
SOUP_CONNECTION_CONNECTING, and connectEnd would be whenever it goes to
some other state (presumably IDLE or IN_USE) after CONNECTING.
Currently there's no way to detect domainLookupStart/domainLookupEnd,
and secureConnectionStart.
The "soup-fly" extension in the epiphany-extensions module on
git.gnome.org gives an example of how to use this stuff.
Oh, I mentioned "semi-private API" before; the SoupConnection object
will eventually be going away when we move to a more gio-based API. At
that point, it's possible this will stop working (probably meaning that
the session would just never emit the "connection-created" signal), but
will hopefully be replaced by a better API.
-- Dan
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]