Server hardcodes Content-Type

[wordofglass]

Hi!

I recently integrated fanart.tv support in beets, and now this issue popped up: https://github.com/beetbox/beets/issues/2053.

The album cover for the album "9" by Damien Rice is actually a png image with a jpg extension. I don't know whether this is just an unfortunate exception or a problem that could sneak into a larger part of the database.
Part of the problem is that the server returns an incorrect Content-Type header for the full-size images (for the website preview, it correctly is image/png). This way we can't correct the extension without an additional filesystem access to check the imager header.

website preview:

Code: Select all

curl -I https://fanart.tv/detailpreview/fanart/music/2119beb8-6ac5-4f21-82a4-b831c90c0024/albumcover/9-4f31935ae2a25.jpg
HTTP/1.1 200 OK
Date: Wed, 22 Jun 2016 10:38:25 GMT
Content-Type: image/png

website full-size

Code: Select all

curl -I https://fanart.tv/fanart/music/2119beb8-6ac5-4f21-82a4-b831c90c0024/albumcover/9-4f31935ae2a25.jpg
HTTP/1.1 200 OK
Date: Wed, 22 Jun 2016 10:38:35 GMT
Content-Type: image/jpeg

API:

Code: Select all

curl -I http://assets.fanart.tv/fanart/music/2119beb8-6ac5-4f21-82a4-b831c90c0024/albumcover/9-4f31935ae2a25.jpg
HTTP/1.1 200 OK
Date: Wed, 22 Jun 2016 10:37:18 GMT
Content-Type: image/jpeg

It would be very nice if you could fix at least the reported Content-Type, if not include a sanity check for uploaded files to only permit correct extensions. Thanks a lot!

[Kode]

The issue is that the image type *should* be a jpg, not a png, the upload already checks the mime type to make sure it matches the allowed type, so not 100% sure how that sneaked through

[Esky]

I've reported the image, so it should get replaced with correct image type in a few days.