You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think if no mimetype is provided in the client call we should probably fallback to application/octet-stream if we can guess with a streaming api it is fine but we if we need to open large file on the server side to guess, it can have a huge impact on performances.
That's why we wanted to have the client giving us the mimetype.
Natim
changed the title
deal with unknown mime types
How do we deal with unknown mime types?
May 3, 2016
if we need to open large file on the server side to guess, it can have a huge impact on performances.
That's why we wanted to have the client giving us the mimetype.
I am not sure that's relevant for the S3 backend (the performance part)
I have not tested this but I think when you get a file in S3 where the Content-Type was not set, application/octet-stream is the default, so a fallback to that value seems a good idea
As seen on Fennec, some boxes just don't have mimetypes registered see:
pocmo/Fennec-DLC-Catalog@b6abf51
we should deal with this in kinto-attachement. https://github.com/Kinto/kinto-attachment/blob/master/scripts/upload.py#L61
maybe by raising an error ? another option is to guess it on the server-side in Kinto when it's not provided by the client maybe ?
The text was updated successfully, but these errors were encountered: