Bug 181377

Summary: [GStreamer][Soup] implement session sharing
Product: WebKit Reporter: Philippe Normand <pnormand>
Component: PlatformAssignee: Philippe Normand <pnormand>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: cgarcia, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Description Philippe Normand 2018-01-08 02:08:28 PST
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...
Comment 1 Carlos Garcia Campos 2018-01-08 02:13:00 PST
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
Comment 2 Philippe Normand 2018-01-16 06:48:53 PST
(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.
Comment 3 Michael Catanzaro 2018-01-16 08:25:55 PST
(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)
Comment 4 Philippe Normand 2018-01-16 09:49:41 PST
(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.
Comment 5 Carlos Garcia Campos 2018-01-16 22:39:29 PST
(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.
Comment 6 Philippe Normand 2018-01-17 01:02:39 PST
(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.
Comment 7 Philippe Normand 2018-01-18 05:23:11 PST
Created attachment 331615 [details]
Patch
Comment 8 Philippe Normand 2018-01-18 05:25:20 PST
Not asking review because the patch requires a bump to unreleased GStreamer 1.14 anyway.
Comment 9 Philippe Normand 2018-01-18 06:49:03 PST
Created attachment 331617 [details]
Patch
Comment 10 Michael Catanzaro 2018-01-19 10:20:32 PST
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?
Comment 11 Philippe Normand 2018-01-29 05:12:53 PST
(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.
Comment 12 Philippe Normand 2019-03-12 11:08:21 PDT

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