Include detected file mime type in validate_mime_type_inclusion errors #608
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The default error message of
validate_mime_type_inclusion
can be confusing to the end user.To give a specific recent example, we validate mime type to be
text/csv
. When a user uploads a CSV file that looks perfectly fine but includes an<html>
tag, Marcel will identify the file astext/html
.To replicate:
Without providing feedback as to what mime type was detected, the user will be unaware what's wrong with their data.csv file when the error they see is File type must be one of: text/csv.
There is currently no way to provide a custom error message with the detected mime type other than writing a custom plugin.
Changes
Include the detected mime type in the default validation error message. This way, the user can review the file and clean it up. In the example above, any HTML in the CSV is undesirable and will cause issues downstream.
Error before: type must be one of: text/csv
Error after:
Considerations
validate_mime_type_exclusion
could be updated the same way. However, the message makes more sense in this case (e.g. the file can't beimage/jpeg
but somehow it isimage/jpeg
.Some documentation could be added about defining a custom message (expecting 2 arguments, not 1) but I wanted to collect initial feedback first.