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 properly get a image/jpeg in the Content-Type header returned when accessing a JPEG in my Mosso Container. Also when debugging Cyberduck, it does set the content type when uploading a JPEG for me. So I cannot replicate this. Will check with Mosso for possible reasons this might fail.
So with some more testing, it appears as if the the user uploads a JPEG with a file extension of .JPG or .JPEG (upper case), the content-type is not being set and defaulting to application/octet-stream.
This does not seem to be isolated to Cyberduck. Uploading through Mosso's web interface also breaks with a .JPEG file extension (although they did handle .JPG). I suspect the mime/content type determination is based on file extension rather than the files "magic number".
Grep'ing through the Cyberduck source, I'm wondering if this is a case-senstivity issue? It seems like the source consults a lib/mime.types file. That file looks like it would map "jpeg jpe jpg" to content-type "image/jpeg". So if the source file is .JPG or .JPEG the match is failing?
When I upload a .jpg with Cyberduck to Mosso Cloud Files and then try to view it with through the CDN with Firefox, it prompts me to download it.
When I do the same thing with a .png it works fine and displays in the browser like it should.
Can we get Cyberduck to the file type on upload appropriately on .jpg and any other files to they are served appropriately?
The text was updated successfully, but these errors were encountered: