I able to upload my file through uploadify + .ashx, but the problem is I always get ContentType = application/octet-stream
Lets say I upload an image, I expected to return me "image/pjpeg", but it always return "application/octet-stream" no matter what file I uploaded.
Please advice how to get the correct contentType in .ashx
I believe that most probably content type is getting set by browser. Regardless, different browsers may set different content type for different files - and they may fall back to generic content type such as "application/octet-stream" for any binary file (pdf, zip, doc, xls). Its possible that one browser would report docx as "application/vnd.openxmlformats" while other as ""application/x-zip-compressed" and yet another as "application/octet-stream". And yet all of them are correct, because docx are binary file and are compressed (zip) files.
In short, my suggestion is that you should not rely on the content type sent by client (beyond certain extent such as deciding whether its text, html or binary etc) and rather use server side sniffing logic to determine type of file content. Simple sniffing can be based on file extension while more robust implementation will loot at actual file contents where typically first few bytes of file indicate the file type.
Related
I need to validate if a file is an image.
Should I check content type or extension? What is more safe / better?
I think checking extension is better - what do you think?
string ext = System.IO.Path.GetExtension(fileName).ToLower();
If all you care for is IMAGE files, then Content-Type is the way to go.
But...
If you DO care for Image type, then you must check by extension, since there really is no true mapping from a content-type to the file extension. For example a content-type of "image/jpeg" could be mapped to either .jpg or .jpeg.
However, if you're talking about checking files uploaded by users, both methods are not safe since they rely on user input. See OWASP: Unrestricted File Upload.
I need a snippet to check file for validity (I'm allowing users to upload xml files). So I need to check whether uploaded file is XML.
The best I can think of is just check if extension is ".xml". What if its replaced?
You can try loading it like this and catch the exception:
XDocument xdoc = XDocument.Load("data.xml"));
Presumably, if they're uploading XML, then you're going to use it for something afterwards. In this case you should validate the XML against a Schema (XSD etc) so that you know you aren't going to hit unexpected values/layouts etc.
In Urlmon.dll, there's a function called FindMimeFromData.
From the documentation
MIME type detection, or "data
sniffing," refers to the process of
determining an appropriate MIME type
from binary data. The final result
depends on a combination of
server-supplied MIME type headers,
file extension, and/or the data
itself. Usually, only the first 256
bytes of data are significant.
So, read the first (up to) 256 bytes from the file and pass it to FindMimeFromData.
If you must validate the xml (assuming you want to validate the entire thing) you can use the XmlDocument class and catch an exception if it's not XML.
I am using file upload mechanism to upload file for an employee and converting it into byte[] and passing it to varBinary(Max) to store into database.
Now I what I have to do is, if any file is already uploaded for employee, simply read it from table and show file name. I have only one column to store a file and which is of type VarBinary.
Is it possible to get all file information from VarBinary field?
Any other way around, please let me know.
If you're not storing the filename, you can't retrieve it.
(Unless the file itself contains its filename in which case you'd need to parse the blob's contents.)
If the name of the file (and any other data about the file that's not part of the file's byte data) needs to be used later, then you need to save that data as well. I'd recommend adding a column for the file name, perhaps one for its type (mime type or something like that for properly sending it back to the client's browser, etc.) and maybe even one for size so you don't have to calculate that on the fly for each file (useful when displaying a grid of files and not wanting to touch the large blob field in the query that populates the grid).
Try to stay away from using the file name for system-internal identity purposes. It's fine for allowing the users to search for a file by name, select it, etc. But when actually making the request to the server to display the file it's better to use a simple integer primary key from the table to actually identify it. (On a side note, it's probably a good idea to put a unique constraint on the file name column.)
If you also need help displaying the file to the user, you'll probably want to take the approach that's tried and true for displaying images from a database. Basically it involves having a resource (generally an .aspx page, but could just as well be an HttpHandler instead) which accepts the file ID as a query string parameter and outputs the file.
This resource would have no UI (remove everything from the .aspx except the Page directive) and would manually manipulate the response headers (this is where you'd set the content type from the file's type), write the byte stream to the client, and end the response. From the client's perspective, something like ~/MyContent/MyFile.aspx?fileID=123 would be the file. (You can suggest a file name to the browser for saving purposes in the response headers, which you'd probably want to do with the file's stored name.)
There's no shortage of quick tutorials (some several years old, it's been around for a while) on how to do this with images. Just remember that there's essentially no difference from the server's perspective if it's an image or any other kind of file. All the server needs to do is send the type in the response headers and write the file's bytes to the client. How the client handles the file is up to the browser. In the vast majority of cases, the browser will know what to do (display an image, display via a plugin a PDF, save a .doc, etc.).
At the moment i get file extension of the file like :
string fileExt = System.IO.Path.GetExtension(filUpload.FileName);
But if the user change the file extension of the file ( for example user could rename "test.txt" to "test.jpg" ), I can't get the real extension . What's the solution ?
You seem to be asking if you can identify file-type from its content.
Most solutions will indeed attempt the file extension, but there are too many different possible file types to be reliably identifiable.
Most approaches use the first several bytes of the file to determine what they are.
Here is one list, here another.
If you are only worried about text vs binary, see this SO question and answers.
See this SO answer for checking if a file is a JPG - this approach can be extended to use other file headers as in the first two links in this answer.
Whatever the user renames the file extension to, that is the real file extension.
You should never depend on the file extension to tell you what's in the file, since it can be renamed.
See "how can we check file types before uploading them in asp.net?"
There's no way to get the 'real' file extension - the file extension that you get from the filename is the real one. If file content is your concern, you can retrieve the content type using the .ContentType property and verify that it is a content type that you are expecting - eg. image/jpg.
Simply put, I'd like someone to be able to click a link, and get a one-time-use pdf. We have the library to create PDF files, so that's not an issue.
We could generate a link to an aspx page, have that page generate the pdf, save the pdf to the filesystem, and then Response.Redirect to the saved pdf. Then we'd somehow have to keep track of and clean up the PDF file.
Since we don't ever need to keep this data, what I'd like to do instead, if possible, is to have the aspx page generate the pdf, and serve it directly back as a response to the original request. Is this possible?
(In our case, we're using C#, and we want to serve a pdf back, but it seems like any solution would probably work for various .NET languages and returned filetypes.)
Assuming you can get a byte[] representing your PDF:
Response.Clear();
Response.ContentType = "application/pdf";
Response.AddHeader("Content-Disposition",
"attachment;filename=\"FileName.pdf\"");
Response.BinaryWrite(yourPdfAsByteArray);
Response.Flush();
Response.End();
Look at how HTTP works. The client (=browser) doesn't rely on extensions, it only wants the server to return some metadata along with the document.
Metadata can be added with Response.AddHeader, and one 'metadata line' consists of Name and Value.
Content-Type is the property you are interested in, and the value is MIME type of the data (study: RFC1945 for HTTP headers, google for MIME type).
For ordinal aspx pages (html, ....) the property is 'text/html' (not so trivial, but for this example it is enough.). If you return JPG image, it can have name 'image.gif', but as long as you send 'image/jpeg' in Content-Type, it is processed as JPG image.
Content-type for pdf is 'application/pdf'.
The browser will act according to default behaviour, for example, with Adobe plugin, it will display the PDF in it's window, if you don't have any plugin for PDF, it should download the file, etc..
Content-Disposition header says, what you should do with the data. If you want explicitly the client to 'download' some HTML/PDF/whatever, and not display it by default, value 'attachment' is what you want. It should have another parameter, (as suggested by Justin Niessner), which is used in case of something like:
http://server/download.aspx?file=11 -> Content-Disposition: attachment;filename=file.jpg says, how the file should be by default named.