[webkit-gtk] Send HTTP header line for every request

Tue Jun 28 03:19:51 PDT 2016

El mar, 28-06-2016 a las 11:57 +0200, Jay Strict escribió:
> On 27.06.2016 14:17, Adrián Pérez de Castro wrote:
> > Quoting Carlos Garcia Campos (2016-06-27 08:21:13)
> > > Of course, we just need to fully understand the problem and
> > > decide how
> > > to make it possible. The easiest solution might be to add support
> > > for
> > > loading JS web extensions. Adri started to work on python web
> > > extensions, I don't know if JS support would be very different.
> > > See:
> > > 
> > > https://lists.webkit.org/pipermail/webkit-gtk/2015-August/002416.
> > > html
> > > 
> > > This would be the ideal solution in my opinion. But we could also
> > > add
> > > API to the UI process to provide a set of headers to be added to
> > > any
> > > request, for example, and use that from the web process. This
> > > would
> > > probably be easier, but we can't add UI process API for every
> > > single
> > > web extension feature required by JS apps, so adding a way to
> > > load JS
> > > extensions would be much better.
> 
> I was thinking of changing the semantics of the signal
> 'resource-load-started', since there is so much confusion about it.
> (Many people expect to be able to connect to this and change the
> underlying request. I did expect this, Michael Catanzaro did expect
> this
> and the stackoverflow answer I linked to did also expect this.)

It's not a matter of changing the semantics, the signal says the load
has already started, so it's too late to modify the request. What is
very confusing is the documentation:

"Emitted when a new resource is going to be loaded. The request
parameter contains the WebKitURIRequest that will be sent to the
server. You can monitor the load operation by connecting to the
different signals of resource."

I guess we copy pasted from wk1 documentation, we should update that to
make it clear that request has already been sent, not is about to be
sent.

> Of course, you then would have to find a distinct name, like
> 'resource-load-start' or 'resource-load-initialize' and maybe
> deprecate
> the old signal ... I don't really know.

Changing the name doesn't change anything, the notification is sent to
the UI process when the request has already been sent. What you want is
WebPage::send-request signal that was added exactly for your use case,
and it's the replacement of the resource-load-started signal in wk1.
Handling this in the UI process would mean that for every single
resource loaded by the web process, we would send an sync message from
the web process to the ui process to allow the user modify or even
block the resource request. That would make the load a lot slower and
would block the application.

> Such a signal used to exist in WebKitGTK1 [1].

WebKit1 was not multiprocess, the replacement for that signal is
WebPage::send-request.

> But I could also understand if you say that this breaks too much API.
> 
> 
> > I do agree with Carlos here, and WebKitGTK+ should provide a way of
> > loading
> > JavaScript web extensions. As for Python, I have a working proof of
> > concept
> > C WebExtension which is a shim that itself loads the Python
> > extension. You
> > can check it here:
> > 
> >   https://github.com/aperezdc/webkit2gtk-python-webextension-exampl
> > e
> > 
> > (I am aware of a couple of people using the code in there as a
> > basis for
> > their Python applications which need a web extension, though in the
> > longer
> > term we will have something similar shipped with WebKitGTK+.)
> > 
> > Having a similar proof-of-concept for JavaScript extensions would
> > be great.
> > Ideally, it would be great to use JavaScriptCore for that, because
> > it is
> > part of WebKitGTK+. As tempting as it might be to use GJS, it looks
> > like
> > sticking to JSC (via Seed, see https://wiki.gnome.org/Projects/Seed
> > ) would
> > be better to have less dependencies in the case where one wants to
> > use
> > WebKitGTK+ *without* having GNOME Shell installed.
> 
> Being able to use WebExtensions from all interpreted languages seems
> nice. Although, I must admit that it is hard for me to fully
> understand
> all that you have said.
> Would this enable me to use WebExtensions in Gnome shell extensions?

Yes.

> Furthermore, I have the feeling that for this to fully take off in
> the
> sense that I can use it in standard Gnome shell extensions is a
> matter
> of several years. :/

I don't know, we just need someone to write the patch, and I'll be
happy to review it.

> 
> 
> Kind regards,
> Jay
> 
> [1]
> http://webkitgtk.org/reference/webkitgtk/unstable/webkitgtk-webkitweb
> view.html#WebKitWebView-resource-request-starting
> 
-- 

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: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20160628/68c4b03b/attachment-0001.sig>