arabenseifer / google-cast-sdk

Automatically exported from code.google.com/p/google-cast-sdk
0 stars 0 forks source link

Media Player Library incorrectly handles encoded forward slashes (%2f) in HLS streamlevel manifest paths #440

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a custom receiver using Media Player Library
2. Via sender, load an HLS manifest that contains stream level manifest URLs 
that contain escaped forward slashes (%2f)

What is the expected output? What do you see instead?
Expected that stream-level paths are not modified in any way. Instead, a series 
of decodeURIComponent then encodeURIComponent's seem to be called on the 
stream-level paths, but forward slashes that were encoded aren't re-encoded 
like other characters are.

http://some-cdn.com/some-bucket/something/somefile_360.mp4.m3u8?base=%2fsome-buc
ket%2fsomething%2f

Becomes

http://some-cdn.com/some-bucket/something/somefile_360.mp4.m3u8?base=/some-bucke
t/something/

(which our CDN barfs on because the base query param slashes are not encoded 
properly)

Original issue reported on code.google.com by j...@pivotshare.com on 3 Dec 2014 at 7:55

GoogleCodeExporter commented 9 years ago
For anyone passing by with the same issue, we worked around it by hijacking 
XMLHttpRequest's open method to correct the URL before the request is made:

<code language="javascript">
var superOpen = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function open() {
  arguments[1] = arguments[1].replace(/\?base=\/some-bucket\//, '?base=%2fsome-bucket%2f');
  return superOpen.apply(this, arguments);
};
</code>

You can use RegExp capture groups if you have dynamic portions in between.

Original comment by j...@pivotshare.com on 4 Dec 2014 at 12:48

GoogleCodeExporter commented 9 years ago
You could also use MPL's host.updateSegmentRequestInfo to correct the url.

Original comment by vadi...@google.com on 4 Dec 2014 at 11:34

GoogleCodeExporter commented 9 years ago
^^ Much cleaner. Thank you very much.

Original comment by j...@pivotshare.com on 4 Dec 2014 at 11:36

GoogleCodeExporter commented 9 years ago
In our case, we needed to use `host.updateManifestRequestInfo` instead since 
this is a manifest-url issue for us, though looking through the library source 
it's likely this would impact segment URLs as well if they contained encoded 
forward slashes.

Original comment by j...@pivotshare.com on 4 Dec 2014 at 11:42

GoogleCodeExporter commented 9 years ago
Closing this issue since there is an existing workaround and we believe this is 
intended behavior.  

Original comment by jonathan...@google.com on 5 Dec 2014 at 7:36