Bug 181377 – [GStreamer][Soup] implement session sharing

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Platform

[Philippe Normand]

souphttpsrc is able to share its session using GstContext nowadays. This is useful for session data (cookies, etc) reuse by adaptive streaming downloaders. Not sure we correctly handle this yet...

[Carlos Garcia Campos]

This is not possible. souphttpsrc is used for HLS and other things from the web process, while the soup session is in the network process

[Philippe Normand]

(In reply to Carlos Garcia Campos from comment #1)
> This is not possible. souphttpsrc is used for HLS and other things from the
> web process, while the soup session is in the network process

Sure, but nothing prevents the player to forge a SoupSession upon request.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #1)
> This is not possible. souphttpsrc is used for HLS and other things from the
> web process

Obligatory reminder that this will break when we sandbox the web process so that it doesn't have network access anymore (which is important)

[Philippe Normand]

(In reply to Michael Catanzaro from comment #3)
> (In reply to Carlos Garcia Campos from comment #1)
> > This is not possible. souphttpsrc is used for HLS and other things from the
> > web process
> 
> Obligatory reminder that this will break when we sandbox the web process so
> that it doesn't have network access anymore (which is important)

Then the webkit+http URI hack should be reverted.

[Carlos Garcia Campos]

(In reply to Philippe Normand from comment #4)
> (In reply to Michael Catanzaro from comment #3)
> > (In reply to Carlos Garcia Campos from comment #1)
> > > This is not possible. souphttpsrc is used for HLS and other things from the
> > > web process
> > 
> > Obligatory reminder that this will break when we sandbox the web process so
> > that it doesn't have network access anymore (which is important)
> 
> Then the webkit+http URI hack should be reverted.

That will not help. Even when we downloaded the HLS stuff with our src element, we did that in the web process. We need a media player associated to the src element for requests to be sent to the network process.

[Philippe Normand]

(In reply to Carlos Garcia Campos from comment #5)
> (In reply to Philippe Normand from comment #4)
> > (In reply to Michael Catanzaro from comment #3)
> > > (In reply to Carlos Garcia Campos from comment #1)
> > > > This is not possible. souphttpsrc is used for HLS and other things from the
> > > > web process
> > > 
> > > Obligatory reminder that this will break when we sandbox the web process so
> > > that it doesn't have network access anymore (which is important)
> > 
> > Then the webkit+http URI hack should be reverted.
> 
> That will not help. Even when we downloaded the HLS stuff with our src
> element, we did that in the web process. We need a media player associated
> to the src element for requests to be sent to the network process.

by media player you mean MediaPlayer*? If so that can be wrapped in a GstContext that the element would query from upstream elements.

[Philippe Normand]

Created attachment 331615 [details]
Patch

[Philippe Normand]

Not asking review because the patch requires a bump to unreleased GStreamer 1.14 anyway.

[Philippe Normand]

Created attachment 331617 [details]
Patch

[Michael Catanzaro]

Comment on attachment 331617 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=331617&action=review

> Source/WebCore/ChangeLog:16
> +        Note: This will break again whenever the web process gets
> +        sandboxed. When that happens we should use the webkit http src
> +        element for all network requests again. That means removing the
> +        webkit+http URL hack from the player and http src element.

The web process sandbox is a short-term goal; if all goes according to plan (which never happens) I hope to have it ready in time for the 2.22 release. So I wonder if it makes sense to do this... is this really movement in the right direction?

[Philippe Normand]

(In reply to Michael Catanzaro from comment #10)
> Comment on attachment 331617 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=331617&action=review
> 
> > Source/WebCore/ChangeLog:16
> > +        Note: This will break again whenever the web process gets
> > +        sandboxed. When that happens we should use the webkit http src
> > +        element for all network requests again. That means removing the
> > +        webkit+http URL hack from the player and http src element.
> 
> The web process sandbox is a short-term goal; if all goes according to plan
> (which never happens) I hope to have it ready in time for the 2.22 release.
> So I wonder if it makes sense to do this... is this really movement in the
> right direction?

What do you mean by "this"?
AFAIU when sandboxing is enabled the web process will no longer have network access, so that means the souphttpsrc element used by GStreamer's adaptivedemux to download HLS fragments will no longer work. They way to fix it would be to undo the webkit+http hacks mentioned above so that the network process is used to download fragments.

I have a proof-of-concept patch which:
1. reverts the hack
2. enable MediaPlayer sharing between multiple webkitwebsrc elements so that the HTTP session data can be reused.

[Philippe Normand]

*** This bug has been marked as a duplicate of bug 189967 ***