[webkit-gtk] Problems with the API to get the TLS certificate

Carlos Garcia Campos cgarcia at igalia.com
Mon Feb 18 07:47:36 PST 2013


The current API to get the TLS certificate of a WebKitWebView is
currently:

gboolean
webkit_uri_response_get_https_status       (WebKitURIResponse
*response,
                                            GTlsCertificate
**certificate,
                                            GTlsCertificateFlags
*errors);

This matches libsoup API and what we did in wk1. Once the load is
committed you get the main resource of the web view, to get the response
from the main resource (and in wk1, then we got the soup message of the
network response). 

In WebKit2, the certificate info is stored in the WebFrameProxy when the
load is committed and then we set that information manually to the main
resource response when received. We've had problems with this in the
past and I had to add some hacks to make sure there's a main resource
loaded when the load is committed (it doesn't always happen when loading
a page from the history cache, for example). And it has been broken
recently again when the main resource is reloaded and the response is a
304 (see bug https://bugs.webkit.org/show_bug.cgi?id=109566). With this
bug we have a main resource when the load is committed, but the response
is received after the main frame load finishes. If the bug is not fixed
we would have to add similar hacks to delay the committed and finished
signal emissions until the response of the main resource has been
received.

I don't want to add more hacks, so I propose to change the API to get
the TLS certificate info. Note also that current
webkit_uri_response_get_https_status might be confusing, because it only
works for the response of the main resource. 

We could add that method to the web view directly
(webkit_web_view_get_https_status) and document that it should be called
after the load is committed, or we could emit a signal and pass the
certificate and tls errors as arguments, but this could be confusing
because there will be a signal to handle TLS errors in the future. Note
that this API is to get the TLS information even when there are no
errors to show information about the certificate. 

What do you think? Any other proposal?
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20130218/dc3dcdd5/attachment.sig>


More information about the webkit-gtk mailing list