MIME type checks should ignore case

[petar11199]

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
2.5.0

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
Custom

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
Google Chrome 74, Windows 10

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

What did you do?

Load HLS stream

What did you expect to happen?
I expected Shaka player to correctly read media type video/MP2T and play the stream.

What actually happened?

Shaka throw 4032 error CONTENT_UNSUPPORTED_BY_BROWSER

This is caused because of the wrong media type case in Shaka player.

As by MDN (author Damjan Bursac), extension .ts should have MIME Type video/MP2T and not video/mp2t which is currently set in Shaka player.

This is mandatory by W3.org and RFC internet standard.

I have submitted a pull request with changes.

Thanks.
Petar Marjanovic

[chrisfillmore]

I didn't read the whole spec but it's not clear to me that it mandates that the characters must be uppercase. It says the mimeType "must be used" but not that it must be used exactly. I think this is a case where it would be safe to ignore case, and just call toLowerCase() after parsing. This may be friendlier to other providers who use video/mp2t.

[petar11199]

@chrisfillmore Every article or spec I found is written with uppercase, also on W3 it clearly says "must be used". But I agree that it may interfere with others and that toLoweCase() should be a better idea. I will update my pull request with those changes.

[joeyparrish]

@petar11199, the RFC for MIME types states that this part is case insensitive. In RFC 2045, section 5.1 ("Syntax of the Content-Type Header Field"), it states:

The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent top-level media types.

The MDN article you referenced is merely a wiki, not an authoritative document. (And I've just updated it.) The RFC you linked to is about RTP, where the name of the encoding may well be uppercase, but that does not mean that the MIME type is mandated to be.

It's worth noting that you're getting this error on Chrome, which does not actually support MPEG2-TS natively. Support for that in Shaka Player comes through transmuxing, and we have to identify TS content accordingly before querying the browser's supported formats. As you and Chris have determined, it seems that we are doing an exact string match for video/mp2t, where we should be ignoring the case.

So yes, please update your PR so that the HLS parser, transmuxer, and MSE polyfill all use toLowerCase(). I think the rest of the instances you found can stay as they are, since they are not comparing against input. Thank you for bringing this to our attention, and thank you for contributing!

[petar11199]

@joeyparrish Thank you for your detailed explanation about this issue. I looked at our competitors streaming players and found out that they were using uppercase so I began to investigate, and finally got here. As of error on Chrome, I am aware that MPEG2-TS is not supported, but I didn't manage to fix it using mux.js for some unknown reason, so I had to look somewhere else.

I will update PR with needed changes as soon as I can.
Thank you again for your time,
Petar

[joeyparrish]

I'll have a fix for this soon, so I'm closing the PR. Thanks!