Fix incorrect text content detection

[wxiaoguang]

Fix #36325

[silverwind]

The file extension for application/vnd.ms-fontobject is .eot as per this. I think it would be better to do this workaround only when the file extension is not .eot (case-insensitive), so that these files can still be detected correctly.

[wxiaoguang]

The file extension for application/vnd.ms-fontobject is .eot as per this. I think it would be better to do this workaround only when the file extension is not .eot (case-insensitive), so that these files can still be detected correctly.

Not everywhere can provide file extension. Or you can implement your proposal in another PR

[silverwind]

Yeah I understand that file extension is not a acceptable parameter for a type sniffer, so I guess if not all call sites can provide a file extension, we may have to disable this .eot detection. Shouldn't really matter much if we disable this detection because it's a binary type anyways, so could not show anything meaningful on the UI?

[wxiaoguang]

You can edit this PR directly to implement your proposal

[silverwind]

No, I don't want to add a file extension parameter to the type sniffer, it's not something a type sniffer should be concerned with.

I was just wondering if the workaround could be moved to the code that calls it (where the extension is available).

[wxiaoguang]

I don't know the details of your proposal, so I can't comment more, and don't see the things to do.

To make code review more efficient, as Linus said: "show me the code" if you have better ideas.

[silverwind]

My point is you are preventing the type sniffer from detecting EOT files via file content. Likely this does not matter in the contexts where the type sniffer is used, but if it does, the file extension could be used as a alternative indicator for that type.

[silverwind]

Oh and btw I would not call golang "Stupid", they are just following the whatwg standard, and the standard is defect imho.

[wxiaoguang]

My point is you are preventing the type sniffer from detecting EOT files via file content.

No, I didn't prevent. Please read the code, or show me a real example.

[wxiaoguang]

Oh and btw I would not call golang "Stupid", they are just following the whatwg standard, and the standard is defect imho.

IMHO they are, since they "insist on adhering to these meaningless, rigid, and unreasonable 'standards'", close the issue without thinking, and "hurting end users, surprising developers, and wasting time on closing these duplicate reports"

[TheFox0x7]

to be fair even if this change would block .eot files from being guessed I really don't see why would someone use this format https://caniuse.com/eot

and the check is bad in general https://www.w3.org/submissions/EOT/
hooking at x00's in version would be less error prone - https://goplay.tools/snippet/_Fp4rACHTXI

[wxiaoguang]

to be fair even if this change would block .eot files from being guessed I really don't see why would someone use this format https://caniuse.com/eot

and the check is bad in general https://www.w3.org/submissions/EOT/ hooking at x00's in version would be less error prone - https://goplay.tools/snippet/_Fp4rACHTXI

Thank you very much for the details, I took that into the new function isEmbeddedOpenType and used the real eot content for testing