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 |
-
-
reviewboard/attachments/mimetypes.py (Diff revision 1) Don't we have to update
reviews/ui/base
to call this in the new way? It is still calling it withmimetype/test
as a string.
Change Summary:
Fix up more out of date documentation.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 2 (+78 -36) |
Checks run (2 succeeded)
-
-
reviewboard/attachments/mimetypes.py (Diff revision 2) We use "mimetype" elsewhere in our documentation (and even within this docstring). Can we standardize on that?
-
-
-
reviewboard/attachments/tests.py (Diff revision 2) No trailing period.
This (and others in this file) are missing the function name being tested.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 3 (+78 -36) |
Checks run (2 succeeded)
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 4 (+77 -35) |
Checks run (2 succeeded)
-
-
reviewboard/attachments/tests.py (Diff revision 3) Does it fail with using
assertEqual
? If we're being impacted by the precision, then we should probably passplaces=1
(I think?) to this.