I'm using an Azure storage account to store images and files as block blobs.
Browsers seem to be able to serve images correctly without an extension as long as the content type property is set. For example this will show up as a normal image: https://navhomeprod.blob.core.windows.net/facilityroomphotos/12
Would it be better for any reason to save the blob name with an extension: https://navhomeprod.blob.core.windows.net/facilityroomphotos/12.jpg
The reason I chose not to have extensions is so that I didn't need an extension field in the database, I could just use ids to serve the images.
Simple answer is no. You don't really need to specify a file extension in order to serve images. The catch here is that content type should be set properly. Content type tells browsers how to serve the content.
Even if you have the extension set but content type not set, some browsers will not be able to serve the content in that case. I have seen many questions where Chrome prompted to download an image file instead of showing the content inline if the content-type of that image file not set properly.
One use case that I could think of where the file extension will be handy is when you download these files on your local computer. Based on the file extension, your local computer would decide the application to use to view/edit these files.
Related
I don't know why, but clicking an anchor link to a .themepack file in Edge causes Edge to change the file extension to ".htm" instead, but only on my site. The .themepack files available on the Microsoft gallery do not behave this way.
Given this, I'm sure it must be a server configuration, but I can't determine how to fix it. At first it was trying to display the .themepack (it's a cab format file) as if it was text, right in the browser. I added the html5 attribute "download" to my <a> tag and that prompted for download, but it still tries to name it as .htm.
Demo of issue:
https://soulcon.com/downloads contains a link to https://soulcon.com/img/SOULCON.themepack
This either tries to show as text, or if you use the page to click the link containing the "download" attribute, it downloads as a .htm file.
Links at https://support.microsoft.com/en-us/help/13768/windows-desktop-themes do not cause this.
Considering this site is on managed wordpress by GoDaddy, I don't have any true direct access to the server.
You need to associate the .themepack file extension with the application/octet-stream MIME type on the server. Ask a support person at your hosting provider how to do that. It may be doable with an .htaccess file.
Worked round the issue by zipping the file.
Here's what I would like to accomplish:
I have a file stored in Windows Azure Blob Storage (or for that matter any file which is not on my web server but accessible via a URL).
I want to force download a file without actually downloading the file on my web server first i.e. browser should automatically fetch the file from this external URL and prompts the user to download it.
Possible Solutions Explored:
Here's what I have explored so far (and why they won't work):
Using something like FileContentResult as described here Returning a file to View/Download in ASP.NET MVC to download the file. This solution would require me to fetch the contents on my server and then stream from my server to the browser. For this reason this solution won't work.
Using HTML 5 download attribute: HTML 5 download attribute would have worked perfectly fine however the problem is that while it is really a very neat solution, it is not supported in all browsers.
Changing the file's content type: Another thing I could do (at least for the files that I own) to change the content type property of the file to something that the browser wouldn't understand and thus would be forced to download the file. This might work in some browsers however not in all as IE is smart enough to go beyond the content type and sees the file's content to determine the content type. Furthermore if I don't own the files, then I won't have access to changing the content type of the file.
Simply put, in my controller action I should be able to specify the URL of the file and somehow browser should force download the file.
Is this something which can be accomplished? If yes, then any ideas how I could accomplish this?
Simply put, in my controller action I should be able to specify the URL of the file and somehow browser should force download the file [without exposing the URL of the file to the client].
You can't. If the final URL is to remain hidden, your server must serve the data, so your server must download the file from the URL.
Your client can't download a file it can't get the URL to.
You can create file transfer WCF service (REST) which will stream your content from blob storage or from other sources through your file managers to client browser directly by URL.
https://{service}/FileTransfer/DownloadFile/{id, synonym, filename etc}
Blob path won't be exposed, web application will be free from file transfer issues.
I'm working on an ASP.NET web application for our corporate intranet users. I have a form where a user should provide a path to the file on the local network (something like "\localServer\someFolder\someFile.ext") without uploading the actual file. The issue is that users don't want to type the whole file path and want to use some kind of visual browse dialog.
The standard HTML <input type=file> element allows to browse for a file, but most of the browsers (except for IE) don't allow to access file's full path, so I think it should be done by some external component like Silverlight, Flash, Java applet etc.
I tried to do it with Silverlight, but I'm getting a SecurityException when trying to access file's full path using Silverlight's OpenFileDialog class.
This java applet http://jumploader.com/demo_images.html seems to do something similar to what I'm looking for, but it's focused on uploading files - I only need to be able to get file's full path and pass it to the server as a string.
Any suggestions would be appreciated.
Telerik ASP.NET AJAX RadFileExplorer has the functionality you're looking for:
http://www.telerik.com/products/aspnet-ajax/fileexplorer.aspx
You can use their Custom File Content Provider to hook the GUI to your server's file system.
http://demos.telerik.com/aspnet-ajax/fileexplorer/examples/server-sideapi/dbfilebrowsercontentprovider/defaultcs.aspx
This should be possible with Flash's uploading capabilities. SWFUpload has an API that you may be able to access from JavaScript to extract the selected file name without actually uploading anything. See docs here, for example getFile():
getFile is used to retrieve a File Object from the queue. The file retrieved by passing in a file id (the id property from a file object) or a file index (the index property from a file object).
I've got a ASP.NET site that's located on a local server (MY_SERVER). And one of the things it does is pull up tiff files which are located on another server (ANOTHER_SERVER). The location of each of these files is stored in SQL. I pull up each of these images and am supposed to display them. The problem is:
the files are not named with a tiff extension (does it matter?)
they aren't displaying at all.
I am using an Image control to display these images, and I'm not sure if it matters that the extension is not set (does the image control know the difference between an jpg and a tiff without the extension?)
I am guessing the images aren't displaying because they are not on the same server MY_SERVER that the images are located (ANOTHER_SERVER). Any ideas on how to fix this?
edit: actually displaying the tiff files were amazingly simple:
protected void Page_Load(object sender, EventArgs e)
{
Response.ContentType = "image/png";
new Bitmap(Request.QueryString["ImagePath"]).Save(Response.OutputStream, ImageFormat.Gif);
}
but because the images are located on ANOTHER_SERVER I still can't access them. I may just do a hack where I copy them to a local directory on MY_SERVER but there's gotta be a simple way to fix this. Anyone?
Are the images on ANOTHER_SERVER accessible via HTTP or are you trying to display them in an img tag using their UNC path?
Since web pages are viewed on client machines, the paths to resources (images/css/scripts etc) must be accessible from the client's machine. Even if they are accessible from the server, if they aren't accessible from the client they won't be viewable.
I suspect in this instance MY_SERVER can access the tiffs on ANOTHER_SERVER, however the path to ANOTHER_SERVER means nothing to the client accessing the page.
You will either need to read the image in from the disk and display it as an image using a customer handler, or expose the images on ANOTHER_SERVER via HTTP and reference them that way (which means the client must be able to directly connect to ANOTHER_SERVER).
Regardless of what tag you use, does ANOTHER_SERVER store the images in an internet accessible location? If not, you cannot serve them directly on the internet. You can try downloading the file with Response.WriteFile.
The <img /> tag is not meant to serve TIFFs. The QuickTime plugin is a free TIFF viewer, but it is not very flexible. Where I work, we use Atalasoft's dotImage, which converts TIFFs to tiled PNG on the fly, but it is not free. I found this CodeProject article. Even if you can transform the image into a web-friendly format, your server-side code might have to cache the file on the web server.
You should be able to display an image from another server if your img tag src is properly setup and the server is accessible. However, I don't believe that most browsers support directly viewing tiff files. There are a number of tiff viewers available (google it).
You might also try an <embed> tag and see if it does the trick (look here). The user's computer would have to know how to deal with tiffs.
I have an asp.net application where the users can upload files to our database.
Sometimes when they upload the files, the content-type is set as "application/octet-stream" which is a binary file.
When I ask the user, they say that they uploaded they say it was a .tif file. Somehow the upload control sets it as "application/octet-stream".
When I upload the same .tif file from my computer it uploads with the correct content type (application/octet-stream).
I am using the following code to get the file extension
fileExtension = filUpload.PostedFile.FileName.Substring(filUpload.PostedFile.FileName.LastIndexOf(".") + 1)
sometimes it returns the file extension as "c:\documen" or "j:\testing" etc. I know that windows doesn't allow special characters in the filename.
You simply can't rely on the browser to submit a usable MIME media type. The client machine may not have any media type information set up for a particular filetype (which is likely the case for TIFF here), or it may not support sending media types at all, or there may be bugs in it (as there have been in the past with IE).
You also can't rely on the browser to submit a usable filename extension. The client machine may not use file extensions to determine the type of the file. (Indeed, Macs and modern Linux use multiple mechanisms to determine type, so any filename extension may be misleading, if one is present at all.)
For that matter, you can't even rely on the browser to submit a usable filename in the first place! Not every OS uses backslash character and dot for directory and extension separators; the submitted filename is effectively an opaque string which you can use for guessing some of the common cases, but you can't consider to be definitive.
So the only reasonable ways to determine the type of an uploaded file are:
Ask the user explicitly what type they're uploading.
Try to guess what type it might be from media type and trailing filename, falling back to asking the user what type it is.
If the types you want to allow are all ones with sniffable headers (as TIFF and most other image formats are), you can work out the type by looking at the contents of the file.
Use functions in the System.IO namespace to parse it out instead.
To get the extension, you would do this:
fileExtension = System.IO.Path.GetExtension(filUpload.PostedFile.FileName);
I believe that the user's browser sends a declared MIME type along with the file. It's then up to the browser to declare the type of the file. Different browsers may have different ability to infer the best MIME type from a file. When you get the file on your server, you might just check for the .tif[f] extension -- that's probably all the checking that the uploading browser will do anyways.