You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The other context-specific sniffing algorithms that would set the computed MIME type to be the supplied MIME type do have a check for this unlike the ones mentioned above.
The text was updated successfully, but these errors were encountered:
This is indeed an underspecified area. If the algorithm can't identify the type of image/audio/video/font, what would you expect to happen? If it returned "application/octet-stream", would that be better than returning undefined? What do the browsers do in these scenarios?
I personally went with returning application/octet-stream in my implementation, and it seems the servo browser engine does the same. I haven't been able to find anything for Chrome, but this line in Firefox seems to suggest an undefined is returned if the algorithm fails to match an image signature they support.
I'm not sure if there is a benefit with choosing to return undefined over application/octet-stream. I chose the latter for my implementation of these algorithms because the rules for identifying an unknown MIME type also returns this if all else fails.
What is the issue with the MIME Sniffing Standard?
Not sure if I overlooked something, but it appears that the sniffing in an image context, audio or video context, and font context algorithms don't handle the case where the supplied MIME type may be undefined due to the fact that the supplied MIME type detection algorithm can either return a MIME type or an undefined value.
The other context-specific sniffing algorithms that would set the computed MIME type to be the supplied MIME type do have a check for this unlike the ones mentioned above.
The text was updated successfully, but these errors were encountered: