Original file extension is not kept for thumbnail and web resolution

[xrotwang]

I found the following inconsistency when trying to infer the file URLs for thumbnails from the URL of the original:

robert@astroman:~$ curl -I http://edmond.mpdl.mpg.de/imeji/file/d2JGQRxO19XTOEXG/36/65/76/23-80fd-4953-bf68-4ae631d111d4/0/original/05952a09064414f3e54f19a689e97cf2.JPG
HTTP/1.1 200 OK

robert@astroman:~$ curl -I http://edmond.mpdl.mpg.de/imeji/file/d2JGQRxO19XTOEXG/36/65/76/23-80fd-4953-bf68-4ae631d111d4/0/web/05952a09064414f3e54f19a689e97cf2.JPG
HTTP/1.1 500 Internal Server Error

robert@astroman:~$ curl -I http://edmond.mpdl.mpg.de/imeji/file/d2JGQRxO19XTOEXG/36/65/76/23-80fd-4953-bf68-4ae631d111d4/0/web/05952a09064414f3e54f19a689e97cf2.jpg
HTTP/1.1 200 OK

I.e. the file name extension of the original (.JPG in uppercase) is retained for the imeji URL, but a lowercased extension is used for the web and thumbnail resolutions. This may be due to the conversion utility used to create these, but I think consistent naming would be desirable.

[xrotwang]

Ok. I understand thumbnail creation a bit better now, I guess. It seems as if thumbnails are always created as image/jpeg - which is a good idea. I would still consider it more consistent, if the original resolution would also get a URL with normalized (lowercased) extension. This would also apply, say, 4-letter extensions of filenames (.tiff or .jpeg) which might be normalized to the three-letter one.

But maybe that would just mean creating some under-specified informal API, which when people come to rely on it will come back to haunt us ...

[natasab]

@xrotwang @bastiensaquet i guess this issue is not relevant any longer? Shall we close it?