GNOME Bugzilla – Bug 709117
souphttpsrc: Need ability to exclude HTTP Range header and set content size
Last modified: 2018-11-03 14:50:04 UTC
Need to be able to disable the inclusion of the range header by souphttpsrc. The HTTP Range header is not allowed for dtcp encyrpted content. Also the HTTP Range header interferes with the usage of TimeSeekRange.dlna.org and Playspeed.dlna.org headers. The Range header should not be included when these other headers are added or for dtcp encrypted content. The proper headers will be added by the dlnasrc element which is a "manager" type element and will set the "exclude-range-header" property on souphttpsrc. The souphttpsrc will still use the starting byte position and all the same logic should be performed by souphttpsrc and basesrc, The attached patch creates a boolean property "exclude-range-header" which specifies if the Range header should be included. The default is false. When false, souphttpsrc will include the Range header as it does currently. When this property is set to true, souphttpsrc will formulate the HTTP request as it does now except it will not include the Range header. It will be the responsibility of the dlnasrc "manager" element to do this. If the HTTP Range header is not included, souphttpsrc will not be able to determine the size of the content. The ability to set the content size is needed when the Range header is not included. This patch adds the ability to set the content size through the "content-size" property. The dlnasrc "manager" element will set the size as necessary such as for dtcp/ip encrypted content.
Which patch?
Created attachment 256121 [details] [review] Proposed patch to add exclude-range-header & set content-size
I'm not sure if this is a good solution, it seems rather specific for this special use case. Maybe we can come up with something better... maybe signals on souphttpsrc to modify message before they're sent and before they're parsed by souphttpsrc.
The "content-size" is already a property so this change makes it "writable". Would you agree it should remain a property? Or should I use a signal to set the property rather than making the property "writable"? The "exclude-range-header" seemed similar to the "include-extra-headers" property that's why I chose to make it a property. Maybe it should be more general purpose such as "exclude-headers" and provide a list of headers to exclude? I am not too familiar with signals. I will investigate more and see if I can propose a solution using signals.
Have discussed this some with another developer, we could have souphttpsrc emit a signal when it is about to send out a request. The request could be modified and returned by listeners. This approach could also replace the "include-extra-headers" property. What do you think?
Could you please provide your name for proper patch attribution? I think making the content-size property writable makes sense. I'm undecided about the range header, I don't like the "exclude-range-header" property either. It sounds like this should all be looked at with the bigger picture (various DLNA use cases we don't handle properly yet, like TIME seeking) in mind, instead doing things piecemeal.
My name is Lori Anderson. I am a consultant with CableLabs. We are currently working on a gstreamer element which we plan to contribute to the GStreamer project called "dlnasrc" which is a manager type element. It supports a media player pipeline within the WebKit framework. The dlnasrc creates a bin and includes the souphttpsrc element a the source for the pipeline. It will also include a dtcp/ip decrypter element (another element we plan on submitting - dtcpip) which is responsible for the decryption of content. My design approach was to minimize any changes to souphttpsrc and exclude any special dlna requirements from souphttpsrc. The dlnasrc element would have the logic to deal with dlna requirements. I am not sure how the process works to submit elements for contribution but perhaps looking at the dlnasrc element would shed more light onto the changes needed to souphttpsrc. How does the process work? I think we are ready to start the submission process.
I have submitted the dlnasrc for contribution to the gstreamer project - see Bug #709455
(In reply to comment #7) > It supports a media player pipeline within the WebKit framework. Wouldn't it be better to use the WebKit HTTP code for that though? Otherwise you don't get cookies, authentication, refers and all that right if you just use souphttpsrc.
I need the dlnasrc to hook up the dtcp/ip decrypter element and WebKit's source doesn't do this. Also, the logic specific to dlna headers is not supported by WebKit's source. In terms of cookies and authentication, it looks like that logic is performed within souphttpsrc rather than provided by WebKit's source (WebKitWebSourceGStreamer.cpp). The other functionality provided by WebKit's source is support for icecast headers. Icecast isn't addressed by dlna specifications so currently not a requirement for dlnasrc.
WebKitWebSourceGStreamer.cpp uses the WebKit infrastructure to pass cookies to the server, add referers and also handle authentication via the normal WebKit ways. If you use souphttpsrc you will need to replicate all this or provide a behaviour that is different from the one that WebKit applications would expect. I think we should try to get something like dlnasrc work with any HTTP source element that provides a specific interface.
The dlnasrc element needs to be used both inside and outside of the WebKit framework. There is another gstreamer based media player which is built within the Rygel framework that also needs the dlnasrc element. It sounds like the cookie and authentication logic is built within the WebKit framework and not GStreamer. I imagine it would not be easy to move it to the gstreamer framework. Sounds like it will need to be duplicated in GStreamer? In terms of your comment - "work with any HTTP source element that provides a specific interface", can you give an example of what you meant by "specific interface"? Thinking in terms of implementation, the media player's pipeline source would determine this is a "dlna" server so I need to utilize the "dlna" interface and include HTTP headers which are specific to dlna. Or this is an icecast server, so I need to utilzie the "icecast" interface and include the ice HTTP headers. Is that what you were thinking?
(In reply to comment #12) > The dlnasrc element needs to be used both inside and outside of the WebKit > framework. There is another gstreamer based media player which is built within > the Rygel framework that also needs the dlnasrc element. > > It sounds like the cookie and authentication logic is built within the WebKit > framework and not GStreamer. I imagine it would not be easy to move it to the > gstreamer framework. Sounds like it will need to be duplicated in GStreamer? Yes > In terms of your comment - "work with any HTTP source element that provides a > specific interface", can you give an example of what you meant by "specific > interface"? The properties and signals on the element, the behaviour it provides. So you could have the same dlnasrc element that can use souphttpsrc or webkitwebsrc without having to worry about what the exact HTTP element is that is used. > Thinking in terms of implementation, the media player's pipeline source would > determine this is a "dlna" server so I need to utilize the "dlna" interface and > include HTTP headers which are specific to dlna. Or this is an icecast server, > so I need to utilzie the "icecast" interface and include the ice HTTP headers. > Is that what you were thinking? That's not what I thought but that's also an interesting idea about how we could define some kind of interface for HTTP elements. Or some helper API on top of that interface which sets specific HTTP headers for example.
What's the plan here?
ping ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/95.