Fix when using Data URIs for the manifest

[unkiwii]

When using Data URIs for the manifest an UNABLE_TO_GUESS_MANIFEST_TYPE is thrown. The mimeType is used to look up the manifesst parser but mimeType is undefined because shaka.net.DataUriPlugin does not return the correct 'content-type' in the header.

With this change shaka.media.ManifestParser (lib/media/manifest_parser.js, line167) can select the manifest parser correctly.

Data URIs used:

data:application/dash+xml,[encoded xml]

and

data:application/dash+xml;base64,[base64 encoded xml]

[joeyparrish]

Looks good to me. Thanks for the patch!

Could you please update the tests in test/net/data_uri_plugin_unit.js to reflect this? There's already one that involves a MIME type, so the testSucceeds() helper just needs an update to check the headers. You can run tests locally with python build/test.py

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

[googlebot]

CLAs look good, thanks!

[unkiwii]

Updated the tests so it checks for the response header.

When no content type is present in the uri, an empty string is returned as the content-type, maybe it should return an text/plain as default. What do you think?

[joeyparrish]

I think an empty string or null is appropriate. I wouldn't fill in defaults for content-type if the underlying transport doesn't have a MIME type concept. It might lead to confusion later.

[joeyparrish]

Everything looks good to me. I'll run it through the build bot.

[shaka-bot]

Testing in progress...

[shaka-bot]

All tests passed!

[joeyparrish]

Thank you for your contribution!