Open MattMenke2 opened 2 months ago
It seems that this lack of clarity occurred in cc81ec4 (#36), where the term "parsable MIME type" was removed, perhaps because the focus of the algorithm is on determining where to get the MIME type from rather than what it means. I'm not entirely sure what the intention is now.
@annevk Can you comment?
in practice the list could be any mix of: https://www.iana.org/assignments/media-types/media-types.xhtml https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types https://pagure.io/mailcap/blob/master/f/mime.types
ive also conglomerated as many as i can find into https://github.com/nektro/zig-mime/blob/main/mime.zig
nektro: I don't believe the spec requires it to be a known MIME type, just one that's theoretically valid.
I don't think removing "parsable MIME type" really changed matters here as that had a rather recursive definition.
https://mimesniff.spec.whatwg.org/#interpreting-the-resource-metadata probably needs to invoke https://fetch.spec.whatwg.org/#concept-header-extract-mime-type and in the cases where the variable remains null, the step quoted in OP applies. And the variable should never be assigned to anything but null or a MIME type.
What is the issue with the MIME Sniffing Standard?
The section "Interpreting the resource metadata" / "To determine the supplied MIME type of a resource" has the step: "If supplied-type is not a MIME type, the supplied MIME type is undefined."
The "MIME type" link doesn't define how to determine whether a string is or is not a MIME type. Does it mean if the "parsing a MIME type" algorithm returns failure, or something else?