We currently rely on the server to provide a valid content-type and if that fails we always use the URL's file name extension instead. The HTML5 specs clearly states that the type of a resource should be determined through sniffing [1] And that sniffing should take precedence over the supplied mime type [2]. Parsing the resource header [3] doing ``` 2. Read bytes of the resource into buffer until one of the following conditions is met: * the end of the resource is reached. * the number of bytes in buffer is greater than or equal to 1445. * a reasonable amount of time has elapsed, as determined by the user agent. ``` For now we will only rely on sniffing should the previous way of determining the content-type failed. [1] https://html.spec.whatwg.org/#content-type-sniffing [2] https://mimesniff.spec.whatwg.org/#rules-for-sniffing-audio-and-video-specifically [3] https://mimesniff.spec.whatwg.org/#reading-the-resource-header
<rdar://problem/124614908>
Pull request: https://github.com/WebKit/WebKit/pull/25883
Committed 276258@main (93f6303ff83e): <https://commits.webkit.org/276258@main> Reviewed commits have been landed. Closing PR #25883 and removing active labels.
likely the same as bug 245428