I think you forgot to include mimetype detection, which is available in an HTTPPostedFile.

 

I can't port my legacy code without it.

Hi:

 

We have considered that property.

 

But the mimetype is sent by the client , It is not trust-able.

 

For example,

 

If we provide a mime type check property , and allow only all "image/*" .

 

A programmer use that property , and do not check the file extension,

 

Then the web application would be very danger , because :

 

If the client send a file , filename is  hack.aspx , but the header data is CONTENT-TYPE:image/jpg

 

The Uploader would accept it, and the hack.aspx would store at server side and may be executed.

 

 

Regards , Terry.

 

 

eBay will accept a jpeg named "image.exe" and do the right thing (try it). And yet, the cutesoft editor demo will not accept a legitimate jpeg named "image.exe". Do you honestly believe that your solution is safer than that of eBay?

 

HTTPPostedFile's contenttype property checks signatures within the bits of the stream to detect mimetype, as does eBay's software.

 

My server software handles uploaded jpegs and gifs differently. I was able to reliably identify jpegs and gifs using HTTPPostedFile. How can I do that with your file upload product? I cannot.

 

 

( http://msdn2.microsoft.com/en-us/library/ms775147.aspx )
 
But even IE would correct the mimetype , the server side should not trust it.
 
Because the client can send invalid/animus data/info by using tool (not using browser).
 
So the uploader can only keep the file extension as safe as possible , but not the mime/data .
 
The best way to check that whether a file is an image , is try to convert the file data to the GDI Image object.
 
I think that is not the function of our Uploader , the developer should do that.
 
 
Maybe we can add mime check for the Uploader, that can help some advanced developers ,

but that would hurt some developers who are not familiar with the mime issue.

 

Regards , Terry .