I am trying to figure out how to get a file that I have stored in my Database, onto the filesystem. I have looked everywhere, but all I can find is like for images pulling them out and serving them via Response. Can anyone point me in the direction of a tutorial or provide me with some input on which way to go?
From the perspective of serving the file through the web, the process is exactly the same for images as it is for any file type. The only difference would be the content type in the response header. (For a PDF, it would be application/pdf.)
Understand that over HTTP there is absolutely no concept of "files." All you have are requests and responses, each of which has headers and data. Whether it's an image, a PDF, a web page, anything... the structure of the response being delivered to the client (browser) is exactly the same. Headers tell the browser what kind of data it is and various other meta-details about it, and the data is just the raw data of the "file" being sent. The browser can choose what to do with the data.
In the case of web pages, the browser generally just renders it. In the case of other or unknown content types, the browser generally prompts the user to save it as a file. (Note that a file name can also be suggested in the header of the response.)
Edit: In response to your comment on #Pete M's answer...
The process is still very similar. "Files" as email attachments work in much the same way as "files" over HTTP. Essentially, all you need is the data stream and the content type. When building the MailMessage object, take a look at the Attachment object. As you pull your PDF file from the database (just like when pulling images from the database to serve to a browser client), set the data stream to the ContentStream on the attachment object. Then also set the ContentType (again, application/pdf) and the Name on the attachment object and you should be able to send it as part of the MailMessage.
You may need to set more options on the Attachment as well. Testing will indicate how explicit you need to be with things like encoding. If you can share some code as you attempt this, we can help you with that code.
It's no different than writing out any other kind of file. If you find a good "read/write text file" tutorial it's going to be the exact same process, you'll just get your initial stream from the database.
Can I ask why you are doing this? If it's for caching so you can return it to users who ask for it I would consider other options first. Requiring a dip into disk will often cause a bottle neck in performance.
Related
I just want to display the links of attachments to download in mail body without downloading the attachment initially. coz i don't want to download and save the attachments on my server everytime.
when users clicks the link, then I want to download that particular attachment(s) from gmail server ("https://mail-attachment.googleusercontent.com/attachment/u/1/?xxxx-xxxx")
is there is anyway to do this?
MailKit does not provide any way of doing this because it's not something that IMAP supports.
That said, it might be possible to figure out how to construct the URL based on the properties of the MIME attachment.
Based on examining the Download link in one of my own emails, it looks like Google uses their X-Attachment-Id header value to construct the realattid portion of the url. They probably have other variables as well, but it's hard to know exactly where the other values come from.
The attid value in the download url appears to be a positional value of the MIME attachment in the tree, similar to MailKit's BodyPart.PartSpecifier string.
Instead of trying to recreate GMail's download link, you could always use MailKit's ImapFolder.GetBodyPart() API to download individual MIME parts when the user requests them.
In order to take advantage of this API, you'll need to call ImapFolder.Fetch() with MessageSummaryItems.BodyStructure.
You can take a look at https://github.com/jstedfast/MailKit/blob/master/samples/ImapClientDemo/ImapClientDemo/MainWindow.cs to see how to use the MessageSummary.Bodyproperty that you get back from the Fetch request.
This is my first time developing this kind of system, so many of these concepts are very new to me. Any and all help would be appreciated. I'll try to sum up what I'm doing as efficiently as possible.
Background: I have a web application running AngularJS with Bootstrap. The app communicates with the server and DB through a web service programmed using C#. On the site, users can upload files and reference them later using direct links. There's no restriction to file type (yet), so just about anything is allowed.
My Goal: Having direct links creates a big security problem for me, since the documents/images are supposed to be private data. What I would prefer to do is validate a user's credentials when the link is clicked, then load the file in the browser using a more generic url path.
--Example--
"mysite.com/attachments/1" ---> (Image)
--instead of--
"mysite.com/data/files/importantImg.jpg"
Where I'm At: Not very far. My first thought was to add a page that sends the server request and receives a file byte stream along with mime type that I can reassemble and present to the user. However, I have no idea if this is possible using a web service that sends JSON requests, nor do I have a clue about how the reassembling process would work client-side.
Like I said, I'll take any and all advice. I'd love to learn more about this subject for future projects as well, but for now I just need to be pointed in the right direction.
Your first thought is correct, for it, you need to use the Response object, and more specifically the AddHeader and Write functions. Of course this will be a different page that will only handle file downloads, so it will be perfectly fine in your JSON web service.
I don't think you want to do this with a web service. Just use a regular IHttpHandler to perform the validation and return the data. So you would have the URL "attachments/1" get rewritten to "attachments/download.ashx?id=1". When you've verified access, write the data to the response stream. You can use the Content Disposition header to set the file name.
Many might have had experience using File Upload widget from Yahoo User Interface library. The docs and community all know how to receive the files on the server using another server technology other than ASP.NET. If anyone has indeed used the widget in their asp.net pages could you share the code on
How to receive the uploaded files Stream/Bytes to a file.
How to check Integrity of the File
How to check if file was received correctly.
Also i would love to do it in single page because doing so i would learn how to differentiate between a normal webpage request and the one caused my file upload widget
Yahoo Upload Widget can be Found here: https://developer.yahoo.com/yui/uploader/.
Have you tried looking at postedfiles collection though? The API looks like it does a standard post. If it does, the just use that collection.
If it doesn't, then you need to use the inputstream property on the request object to read the incoming bytes.
Using something like Fiddler or firebug will tell you how it's making the request. Look for the request type being multipart/mime
edit
Checking the file integrity & whether it was uploaded correctly are pretty much impossible. The only way I can think to do it is to have the user generate a hash of the file then upload the file & the hash & you check the hash is valid. ie not really practical.
All you're getting is a stream of bytes. you have to assume when the stream ends, it ended cleanly & you got all the file.
I answered my own question with code over here.
http://labs.deeptechtons.com/asp-net-tuts/how-to-upload-files-asynchronously-using-yahoo-uploader/
Is it possible to get file properties of a web file. ie: PDF file and get the date and time the PDF file was modified. Thanks.
You're probably looking for the HttpWebResponse.LastModified property.
No, you can't. It's not a file, it's a resource.
When you request it from the server you get a response back. In this case the server uses a file as source for the resource, but it could just as well be something that is just created on the fly. You only get the information that the server chooses to put in the HTML header.
You might however be able to get some more information if the server returns directory information. Then you could request the folder and get a listing back, from which you could parse some information. Note however that it's not certain that the server actually uses the files when you request something from the directory, it could still return something completely different. Also, the directory listing is also a resource, so there is no guarantee that it's relevant either.
I have a device that uses a custom scripting language. This language provides the capability to set http request headers then perform a post to a URL. The server that the device communicates with is running .net, and I would like the handler on the server to retrieve data from the device by simply pulling it from the Request.Files[] collection. To do this, does the device need to support multipart posting or is it possible for the uploaded content to show up in the Files collection by simply setting a number of headers then sending the data?
I'm not a linux guy, but I did a search and I found this. Does it help at all? (see section 4.3)
http://curl.haxx.se/docs/httpscripting.html
If you mean that at the server end you want the file(s) to be readable via HttpRequest.Files, then I believe so.
I think the format that this expects is based on the File Upload RFC and therefore if you follow the standard procedure for submitting a file upload then it'll work.
As to how you go about formatting the request from your device - I'm afraid I can't help on that one. Assuming you can format an Http Post, writing any headers you need and then formatting the Post body with the file content, it'll work, though.
In order for .Net to be able to read a file posted to a header it must be in the multipart posting format. Otherwise it will just be text noise in the header and .Net won't know what to do with it.