On Fri Jul 8 14:14:30 2022 +0000, Gabriel Iv��ncescu wrote:
But the content type does not seem to be set without a Content-Type response header (which is the reason for the first commit), so detection is still useful as a fallback in case the response does not provide one. As for why it's specific to XHR, I thought it used the same underlying code path, but I could be wrong. Not sure how to "special case" it though. It didn't break any tests, so it's either correct or we clearly lack tests in this area. Do you have some in mind how to add tests for this (without XHR)?
There are two aspects of it. One is embedding API, with with loading must cooperate. It's especially important for the main document binding, which may in fact be initialized by things like BingToObject(). It's much less of an issue for XHR.
The other aspect is what Gecko expects and the best way to learn that is in source code. Running tests with random changes may be an interesting observation, but does not prove much. In this case our implementation replaces original Gecko protocol implementation. An equivalent code would be: https://gitlab.winehq.org/wine/wine-gecko/-/blob/master/netwerk/protocol/htt... NS_SniffContent() call concept seems similar to urlmon MIME validation and it's controlled by LOAD_CALL_CONTENT_SNIFFERS, so maybe we could use that to decide on MIME source preference?