This is related to#33, but subtly different. As explored inwhatwg/mimesniff#30 browsers have different code paths for request and responseContent-Type header parsing. Values such as*/*, text/html in a responseContent-Type header end up being interpreted astext/html, presumably for compatibility with deployed content.

This seems like another fallout of intermediaries adding potentially duplicate headers and (early) implementations being poorly tested for erroneous input.