Open Bug 1889098 Opened 6 months ago Updated 6 months ago

mimetype provided by the server should be used after sniffing fail

Categories

(Core :: Audio/Video: Playback, enhancement)

enhancement

Tracking

()

People

(Reporter: padenot, Unassigned)

References

Details

Currently, when opening a resource we run the nsMediaSniffer to determine the type of content.
We ignore the mimetype provided by the server.

We did so to prevent false positive a while back.

However, looking at the spec, we see:

https://html.spec.whatwg.org/#loading-the-media-resource:
When the load() method on a media element is invoked, the user agent must run the media element load algorithm..

The load algorithm:
https://html.spec.whatwg.org/#media-element-load-algorithm ->

if the source is local:
If the current media resource is a raw data stream (e.g. from a File object), then to determine the format of the media resource, the user agent must use the rules for sniffing audio and video specifically. Otherwise, if the data stream is pre-decoded, then the format is the format given by the relevant specification.

https://mimesniff.spec.whatwg.org/#rules-for-sniffing-audio-and-video-

In step 4 we read at the end of the steps: "The computed MIME type is the supplied MIME type. "

supplied mimetype is defined as " A supplied MIME type, the MIME type determined by the supplied MIME type detection algorithm."

"If the resource is retrieved via another protocol (such as FTP), set supplied-type to the MIME type as determined by that protocol, if any. "

As such, if sniffing failed to determine the type, we should be using the server's resource provided mimetype.

Lots of discussion in bugzilla.mozilla.org/show_bug.cgi?id=1496497, that is now about something else.

You need to log in before you can comment on or make changes to this bug.