[Webkit-unassigned] [Bug 34003] [GTK] Pass cookies to GStreamer

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Sebastian Dröge <slomo at circular-chaos.org>  2010-01-23 01:39:47 PST ---
(In reply to comment #7)
> (In reply to comment #5)
> > Dan Winship told me yesterday that another solution would be to copy the webkit
> > soup session and hand it to gstreamer.
> > 
> > I believe this solution would be more future-proof, because at some point we
> > will need more context: referrer, auth/ssl, proxy (not sure if it's relevant
> > for webkit/gnome, but that's the idea)...
> 
> and also, then if the server response with a redirection, you can look up the
> right cookies for the new host, instead of continuing to send the cookies for
> the old host...
> 
> (I don't know if that's relevant in practice... I can imagine something like a
> video.google.com URL redirecting to youtube.com though...)

Yeah, I thought about that one too. It might be a good idea to let souphttpsrc
notify about redirects so apps can do whatever is necessary for that URI
redirect (cookie updates, storing the real URI somewhere, whatever)

> (In reply to comment #6)
> > Problem with this is, that SoupSession is not threadsafe unfortunately
> 
> (SoupSession*Async* that is.) Ah, yes, there is that. Or more importantly, it
> can only have a single GMainContext, and IIRC souphttpsrc wants to set its own
> GMainContext on the session so that it control when I/O is and isn't happening.
> (The libsoup i/o rewrite / gio-ification might solve this problem.)

Yes, souphttpsrc is using it's own GMainContext and runs it's own GMainLoop on
it in another thread (one of the reasons being, that GStreamer doesn't require
a main loop running in the default main context).

> It's possible you could share SoupSessionFeatures (cookie jar, proxy URI
> resolver, etc), without sharing the whole session. Some of them might not
> currently be thread-safe, but they could be fixed.

That's the thing I thought about tonight... I guess it would be possible and
probably a good idea to add a SoupSessionFeatures property, then webkit can set
it's CookieJar, proxy stuff, etc.

I was just worried about them not being threadsafe either.

(In reply to comment #8)
> 
> You have a number of style problems in this patch - mostly spaces between
> function names, and parenses, and misplaced *.

Yes, I noticed. But I wanted to get this patch in bugzilla before I left
yesterday to get some first reviews until I'm back :)

> Other than that, the patch looks
> good. I would still prefer to be able to set the same cookie jar, though,
> because I'm pretty sure we'll hit some corner case this is not going to work
> for. We might as well consider, for the future, writing a custom source that
> uses WebCore's machinery to download the video data, by the way.

Another possibility, yes. totem's mozilla plugin does something like this for
example.



Ok, so would you guys all be happy if souphttpsrc gets a property, that takes a
GValueArray of SoupSessionFeature? (And of course style fixes everywhere)

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