Image content-type headers

[Fukushousha]

Hello,A really quick question to which I just can't find the answer. Basically with my fetch user image I get the image type from the DB (which is stored by looking at the extension) and then give out the appropriate header like that :

switch($imagetype){	case ".jpg":		header("content-type: image/jpeg");		break;	case ".gif":		header("content-type: image/gif");		break;	case ".png":		header("content-type: image/png");		break;	default:		die("Something is really wrong if you get here.You got no imagetype from the DB");}

My question is .. okay ... but what for all other image formats. I actually had forgotten them because I saw only these 3 headers. What should I do with all the other image types?

[Jesdisciple]

Why do you need to send that header? Why not just save the image in the filesystem, put its path in the DB, and let the server take care of the media type?Also, which other image formats do you mean? http://en.wikipedia.org/wiki/List_of_file_formats#Graphics

[Fukushousha]

I used this method because that is what I understood from this post by someguy.And yes I do realize there are too many formats out there >_< It would be 100% simple to tell them I accept only these 3 and that's that. Would that be bad? I am tempted to do so.

[Jesdisciple]

I think you should make a new DB table to map file extensions to media types. Here are some other common ones:

.bmp  | image/x-ms-bmp.jpeg  | image/jpeg.svg	| image/svg+xml.tif	 | image/tiff.tiff	| image/tiff

NOTE: I cannot understand how the image/tiff-fx type fits in, but it's used for something... See http://en.wikipedia.org/wiki/Tagged_Image_...Format#See_alsoEDIT: This could also solve the issue of all the different extensions if you let users submit others for your approval.EDIT2: But I still wonder why you need to put the image data in a DB...

[Synook]

EDIT2: But I still wonder why you need to put the image data in a DB...

Portability, organisation, space, integrity.One of my apps used to store images in the filesystem and paths to them in the DB. However, while the database was regularily backed up it was harder to do the same for the filesystem, especially as they had to all go in different folders, and when the server crashed all the images were lost.Also, say you had a user based system. If you wanted to be able to delete user's images if they leave, it would be much easier to simply call a constrained DELETE on the database then have to create new folders on the filesystem for every user and delete them when they leave.

What should I do with all the other image types?

I think you'd like what is in the $_FILES['userfile']['type'] index...

[Fukushousha]

Yeah I know the $_FILES['file']['type'] but I was reluctant to use it because of the post I linked by someguy in my post above. Anyway I will figure something out. Thanks for the advice people

[boen_robot]

One of my apps used to store images in the filesystem and paths to them in the DB. However, while the database was regularily backed up it was harder to do the same for the filesystem, especially as they had to all go in different folders, and when the server crashed all the images were lost.

How come you're doing a backup of the DB and not the rest of the data? What if you stored your app in the same place as the images (or was that exactly the case?). Do you want the app itself to be lost? I mean, what good is a DB without an app to use it?

Also, say you had a user based system. If you wanted to be able to delete user's images if they leave, it would be much easier to simply call a constrained DELETE on the database then have to create new folders on the filesystem for every user and delete them when they leave.

If you store the path to the image, it's equally easy to place an unlink() call on the image path, and only then delete the user's records. It may be slightly more resource expensive (you need two queries, one for selecting the image path, another one to delete the user record), but a user leaving is a one time action anyway.

I think you'd like what is in the $_FILES['userfile']['type'] index...

Even that is error prone. Not only that user agents may send a wrong MIME type (or one that only they can understand), but they may also not send a MIME type at all if they don't know it.If you ask me, it's pretty safe (from both a server and a user perspective) to only whitelist accepted image formats and decline the rest. Unless of course you're providing some sort of free (image?) hosting service where you don't care about the users' data. In that case though, unless you whitelist extensions, your users might upload pretty much any file (even an executable one), so in practice, whitelisting is a must.

[Jesdisciple]

If you ask me, it's pretty safe (from both a server and a user perspective) to only whitelist accepted image formats and decline the rest. Unless of course you're providing some sort of free (image?) hosting service where you don't care about the users' data. In that case though, unless you whitelist extensions, your users might upload pretty much any file (even an executable one), so in practice, whitelisting is a must.

I agree with that, but I think the whitelist could be elastic as I described above. But that would require either administrator verification or a wiki-esque setup with an uneditable blacklist for extensions like exe.