[Webkit-unassigned] [Bug 134830] [GTK] Allow the user to create a WebKitCertificateInfo

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=134830





--- Comment #6 from Carlos Garcia Campos <cgarcia at igalia.com>  2014-07-21 04:50:38 PST ---
(In reply to comment #3)
> (From update of attachment 234755 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=234755&action=review
> 
> > Source/WebKit2/UIProcess/API/gtk/WebKitCertificateInfo.cpp:54
> > + * @tls_errors: #GTlsCertificateFlags verification status
> 
> I don't understand this parameter very well, I don't remember certificate errors reporting very well, but this is a good indication that we should probably improve this. Does this list the types of errors that should be accepted by the exception?

That pair is what you get from soup_message_get_https_status() or webkit_web_view_get_tls_info(). WebKitCertificateInfo was added later. I agree it's a bit confusing, WebKitCertificateInfo contains the certificate itself and possible TLS errors of the certificate or 0 for valid certificates. In WebCore CertificateInfo contains the pair, because DidCommitLoad message contains a CertificateInfo parameter, and in that case we need both. WebKitCertificateInfo was exposed when we added the API to handle TLS errors and add exceptions for certificates. The idea was that you get a WebKitCertificateInfo in WebKitWebView::failed-with-tls-errors that you can use to get the TLS info and use also later to add an exception. This made the API a bit inconsistent with webkit_web_view_get_tls_info(). So, maybe we could rethink the whole thing now that we are breaking the API. The WebKitCertificateInfo is not really needed for webkit_web_context_allow_tls_certificate_for_host() since only the certifica

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.