Jump to content

Image content-type headers


Fukushousha
 Share

Recommended Posts

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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...
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...