Bug 181377 - [GStreamer][Soup] implement session sharing
Summary: [GStreamer][Soup] implement session sharing
Status: RESOLVED DUPLICATE of bug 189967
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Philippe Normand
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-08 02:08 PST by Philippe Normand
Modified: 2019-03-12 11:08 PDT (History)
2 users (show)

See Also:


Attachments
Patch (15.77 KB, patch)
2018-01-18 05:23 PST, Philippe Normand
no flags Details | Formatted Diff | Diff
Patch (15.77 KB, patch)
2018-01-18 06:49 PST, Philippe Normand
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 ***