[wp-trac] [WordPress Trac] #39963: MIME Alias Handling

[WordPress Trac]

#39963: MIME Alias Handling
-------------------------+------------------------------
 Reporter:  blobfolio    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by blobfolio):

 Replying to [comment:7 eddiemcham]:
 > Would this also cover web fonts (x-font-woff => font-woff)? That would
 really help my team.

 Yup, although `application/font-woff` isn't technically correct either
 (see e.g. https://www.iana.org/assignments/media-types/font/woff).

 In a nutshell, the point of this enhancement is to deprovincialize
 WordPress' singular concept of MIMEs (in both time and space). Aside from
 increasing the explicit MIME relational data by over 17x what WordPress
 has currently (making it the largest single collection on the planet,
 haha), it also has automatic detection for `whatever/x-variants` (e.g.
 your `x-font-woff` vs `font-woff`, non-MIME parent class nonsense (like
 `application/ms-office`, which is not, nor has never been, a valid media
 type), and won't, by default, penalize generic `application/octet-stream`
 associations (which, while it can be a valid type, is more often just
 `fileinfo`'s equivalent of a shrug).

 WordPress isn't likely going to rollback or narrow the security fix that
 is causing all the collateral damage, but at least with MIME alias
 support, we can seriously mitigate almost all of the incorrect
 identifications people are seeing on various server environments (while,
 crucially, not defeating the purpose of the security fix in the first
 place!).

 If you need a fix sooner rather than later, shoot me a message on Slack or
 email me (contact info can be found at the URL linked in my profile; it
 gets stripped if I try to post it directly here) and I can package this up
 as a quickie plugin for you. One of my clients is a font foundry and has
 had no problem uploading WOFF, WOFF2, TTF, OTF, SVG, etc., files to their
 site with this workaround.

 I know you said you didn't want to add more overhead to your sites, which
 is understandable, but a surgical workaround is going to be a lot safer
 than allowing unfiltered uploads or disabling the security checks
 altogether. ;)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39963#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform