Bug 70000 – Requests for <video> & <audio> not using headers modified in "resource-request-starting" handler

• Status: UNCONFIRMED
• Component: WebKitGTK

[Jason Gerard DeRose]

I have a WebView subclass called CouchView that transparently adds a Basic Auth or OAuth header in a handler for the "resource-request-starting" signal:

http://bazaar.launchpad.net/~novacut/userwebkit/trunk/view/head:/userwebkit.py#L71

I'm using this for talking to desktopcouch.  It works great for everything except the source of <video> and <audio> elements.  Some debugging print() in CouchView shows that CouchView is definitely adding the correct header, but watching the CouchDB logs shows that the auth header isn't being sent to CouchDB.

My hunch is the reason for this is that GStreamer rather than WebKit is making these HTTP requests, and GStreamer must be getting the headers before the "resource-request-starting" handler.  Or something like that.

I'm happy to provide additional debugging info, although I'm not too WebKit savvy, so I'll need a bit of hand-holding.

[Philippe Normand]

The HTTP request is made through WebKit, via our webkitwebsrc element. Maybe there's a small bug there.

Is there a simple code sample I can try here to reproduce the problem?

[Philippe Normand]

Ah, indeed the webkitwebsrc should probably emit that signal before sending its network request :)

[Jason Gerard DeRose]

Philippe,

Thanks for taking a look at this! So do you still need a test case for this?  I can whip up a self-contained test case with fewer moving pieces.

Also, thanks for all the great GStreamer + WebKit work you've been doing!

[Philippe Normand]

I'm a bit puzzled about this, while I now understand the problem I don't think the fix proposed is good. It would break the separation between WebCore and WebKit, eg, we'd need to get access to the WebView from the webkitwebsrc element which is in WebCore so as to emit the signal you want to catch in your application...

While I understand your (not so common, I think) use-case I need to chew this a bit more :)

[Martin Robinson]

Do other ports pass these events the API layer?

[Philippe Normand]

(In reply to comment #5)
> Do other ports pass these events the API layer?

Doesn't seem so, or I missed it!

[Jason Gerard DeRose]

So as far as separation between WebKit and WebCore... is there a lower level API that would be a more appropriate place for me to modify the request headers?  Disclaimer: that might be a dumb question as I don't understand what WebCore is ;)

Although I certainly appreciate wanting to keep the architecture layers cleanly separated, I'll admit this is pretty confusing and inconsistent from the perspective of a developer learning the WebKitGtk API... headers are modified for say an <img> src, but not for <video> and <audio>?  For the longest time I thought there was a weird bug in my code or in CouchDB.

While this use case is uncommon now, we aim to make it quite common, and I think it's going to be something that a lot of great UI designers will really go crazy for:

http://vimeo.com/groups/novacutartistdiaries/videos/29748141

And we want GStreamer to be front and center here as having an industrial strength multimedia backend at your fingertips makes things far more interesting.  Anyway, food for thought.

Thanks!

[Martin Robinson]

CCing Eric Carlson, since I think his input here would be valuable. It seems bad to make this change just for the GTK+ port, but I can see something like this being useful for all ports.

[Eric Carlson]

Would it work to add MediaPlayer interfaces to pass a dictionary of headers to the platform media player? 

We will also need to be able to get headers from a media resource to support CORS, might want to add that at the same time.

[Philippe Normand]

(In reply to comment #9)
> Would it work to add MediaPlayer interfaces to pass a dictionary of headers to the platform media player? 
> 

We can do that yeah but how would the application developer use this feature?

> We will also need to be able to get headers from a media resource to support CORS, might want to add that at the same time.

That's a good point!

[Joonas Lehtinen]

This probably the same bug that prevents Safari from accessing audio resources restricted only to a specific (cookie based) user session. 

For an example, see this audio visualization test application built with Vaadin Framework: http://vj.jole.fi/ with Chrome and Safari/Webkit. Safari (probably) doesn't pass cookie headers properly with the second request and thus initial audio request is left to "(Pending)" state.