- Limits on file size
- General protections / limits - currently using secure_filename
If using a cloud storage provider one of the following must be true:
- No extension is set and response header
content-typeis set correctly. For example filename is
example(note no extension) with content-type
- A valid extension is set. For example, for images, the URL path ends with
[.jpg, .jpeg, .png, .bmp, .tif, .tiff]
The content-type metadata might not be set correctly.
When possible we use the filename as determined by the URL as the 1st choice.
In theory this will return None if it can't detect it, and fallback to checking the content-type.
The reason we want to detect the content type is
- To know what type of pre-processing to do.
- To not download completely arbitrary files
- To instruct the frontend on how to handle the file.
is basically a "not found" content type
But since now we try to check the URL first,
if we see this, then we still return that as part of the failed
extension type, not a seperate error.
(We now error directly on having both media type None and content type
Updated 4 months ago