Make mimetype match scoring much stricter.
Review Request #10226 — Created Oct. 12, 2018 and submitted
When we initially created the mimetype matcher, it was okay to get some
false positives, because all it was used for was choosing an icon to
show for the file attachment. We now no longer have icons at all, but we
do have review UIs which behave completely incorrectly when there's a
bad file type. We recently addedapplication/x-javascript
to the
TextReviewUI
, but this was matching all sorts of incorrect files, like
application/msdownload
andapplication/x-pdf
.This change tightens up the scoring system a lot more, making it so that
if there aren't wildcards, both the type and subtype have to match
exactly. The addition of a vendor tag will cause the match to score
higher, but is not required.
Ran unit tests.
Description | From | Last Updated |
---|---|---|
Don't we have to update reviews/ui/base to call this in the new way? It is still calling it with mimetype/test … |
brennie | |
We use "mimetype" elsewhere in our documentation (and even within this docstring). Can we standardize on that? |
chipx86 | |
:py:func, since mimeparse isn't a class. |
chipx86 | |
Should be in alphabetical order. |
chipx86 | |
No trailing period. This (and others in this file) are missing the function name being tested. |
chipx86 | |
Does it fail with using assertEqual? If we're being impacted by the precision, then we should probably pass places=1 (I … |
chipx86 |
- Change Summary:
-
Fix up more out of date documentation.
- Commit:
-
dfd4e29d43d8d8b5cebfcdf107aea06a4b2d4cdea31878f61900a3a474b69b02f5a66458dd63ee6c
Checks run (2 succeeded)
- Commit:
-
a31878f61900a3a474b69b02f5a66458dd63ee6cecf43e476313abf44ca11e4ed0f639d84e170418
Checks run (2 succeeded)
- Commit:
-
ecf43e476313abf44ca11e4ed0f639d84e170418e8c75934abaff8ccafecd9533860dd76e5a890ad