I am trying to allow the user to download an excel file, by using
Response.Redirect(
"http://localhost/myapp/download_folder/example excel file_july.xls")
in page load of an ASP.net page
but on the client side i a m getting the following screen in firefox 3.5
You can observe that the file name and file type are shown as empty fields. The ok and cancel buttons are not doing anything.
This happens only in firefox 3.5, it is working in firefox later versions and other browsers.
I tried clearing the Response with Response.Clear(), using Response.BinaryWrite with the file byte array and even tried to open the file with the javascript by calling window.open(url).
you are doing it the wrong way.
just as an example, look at what is done in the question body here:
How to download file and reload
in your case you should probably use an overload of Response.Write.
the point is that you should set some Response headers to tell the browser file name, file length and content type at least.
Related
After uploading a PDF to the Media Archive, I am trying to link to it from a page on a site.
While editing content, I use the hyperlink tool then select the PDF I want to link to via the URL input box.
After saving and publishing the content, clicking the link downloads the PDF and I don't see any apparent way to make this view-able in the browser by using the current Media ID Composite provides. When rendered, we get this:
pdf
Is there a way that I can reference a PDF without using the Media ID and simply use the file name instead?
Here is the Request/Response header info:
After reading what Pauli Østerø said, I understand the problem but am still not able to think of a solution.
I can get the PDF to view in the browser by adding ?download=false to the href URL via Developer Tools. But when I try to add ?download=false to the href through Composite, it doesn't take affect and I get the console output: "Resource interpreted as Document but transferred with MIME type application/pdf: "http://c1.wittenauers.com/media/4afb7bc8-f703-469d-a9b2-a524d8f93dcb/ryc7iw/CompositeDocumentation.PDF"."
Here is the network trace that was asked for by Pauli. In the image, I included the bit where I add ?download=false to the URL, in source view, just in case there could be another way to add it.
Edit: URL and headers for the page.
Here is the link to the page that contains the link:
http://c1.wittenauers.com/cafe/test
Here is the headers for the page containing the link:
From what you're experiencing, it seems to me that Composite have gotten the MIME type of your uploaded file wrong, and is therefor not correctly telling the browser that this file is a pdf, and the browser doesn't know what to do with it.
Try deleting the file and uploading it again.
Try add ?download=false and the end of the href to the file. You prob. need to go into source mode of the content editor.
This is the exact line in the Source Code which is responsible for this behavior, and the logic is as follows
If there is no Querystring named download, the attachment is determined by the Mime Type. Only png, gif and jpeg will be shown inline, the rest will be shown as attachment.
If there is a Querystring named download with a value of false, it will override the Mime Type check and always force the Content-Disposition to be inline.
I made a quick test here to show that the behaviour is a expected. At least in my Chrome browser in Windows 8
Force download: https://www.dokument24.dk/media/9fdd29da-dde8-41f7-ba4c-1117059fdf06/z8srMQ/test/Prisblad%202015%20inkl%20moms.pdf
Show in browser: https://www.dokument24.dk/media/9fdd29da-dde8-41f7-ba4c-1117059fdf06/z8srMQ/test/Prisblad%202015%20inkl%20moms.pdf?download=false
Expanding on Pauli's answer, you can add the following snippet to your page template to automatically add the '?download=false' to all pdf links.
$("a").each(function () {
if (this.href.includes(".pdf")) {
this.href = this.href + "?download=false";
}
})
Is there a reason that I should not be sending my content-type as binary for everything? I am a bit naive about proper http but it seems to work for everything. What are some of the pitfalls I will run into working this way?
If you send a stylesheet as Content Type binary, IE9 won't render it. It refuses to render any stylesheet that isn't text/css. That's probably enough to keep people from not visiting your site with IE9.
Not to mention the other benefits like the browser handling specific content types differently based on user preferences.
http://blogs.msdn.com/b/ieinternals/archive/2011/03/27/http-406-not-acceptable-php-ie9-standards-mode-accepts-only-text_2f00_css-for-stylesheets.aspx
Edit
Here, you can use this, it will make it easier to determine the content type. The module will have two methods. getExt and getContentType. If you pass the extension to getContentType it will return the Content-Type for that file. I'm not the one that compiled all the content types, unfortunately I forgot where I found it...
https://gist.github.com/976610
If you specify the right content-type, the application/browser requesting the file can handle it properly
For example, if You're downloading a pdf file, the browser knows how to handle the content type "application/pdf" and will open the file directly in the browser, if it doesn't know the type, it will just ask you to download the file
Browser also let you specify a specific program from which you can open a specific type of file, for example, if you download a torrent file, you can tell your browser to open it with uTorrent, and the next time a torrent file is downloaded it will be also opened with uTorrent directly
In Node.js, you can get the content type of a file doing the following:
type = require('mime').lookup(path);
I am supporting a site for a client on the intranet. The site contains links to xml files. These xml files have a unique extension and are intended to be opened by a specific application. Using IE 8, we could support this by setting the option ‘Open files based on content, not file extension’ in Internet Options -> Security -> Custom Level. In IE 9, this option has been removed. Now these files open a new tab and display the xml.
Ideally, I’d like the file to just download through the download manager, but opening file in the application on the client machine would be acceptable as well. What is the best way to do this in IE 9? Is there a setting that I should adjust? Server side, I have tried adjusting the MIME type, but it seems that if I sent it to something unknown (e.g. application/octet-stream) IE determines the content. The last option I could think of would be to adjust the links such that they call an asp.net page that loads the contents of the xml into the response object but changes the header to contain Content-Disposition:"attachment;filename=file.ext”.
Any advice on the best way to solve this problem?
Content-Disposition:attachment is what you are looking for, yes. That is how you instruct browsers to download the file separately, and not try to display it.
You could use routing or rewriting to keep your file URLs, but have an ASHX handle the file so it can set that header. (don't use an ASPX; it's more than you need to just set some headers)
I think the work around that I was looking for was the fact that the 'Open files based on content, not file extension' option in IE8 was renamed, 'Enable MIME Sniffing' in IE9. But Andrew Barber's answer is the correct solution.
I'm using uploadify (http://www.uploadify.com/) to upload video to my site then convert them into *.flv using ffmpeg and play preview. But it dosen't fully working with firefox， chrome or safari.
uploadify provides a onComplete interface, so when the script (.ashx, .php) used on your site for saving uploaded files. you can use response.write("blabla") or (echo "blabla") to invoke the javascript function that registed as OnComplete.
i have test with few video files like avi, mpg, mp4, they are less then 50mb,and they all worked with all 4 browsers. However, when i was trying to upload a 75mb mp4 file, it worked in IE, but didn't working in other three. I can see the .flv file has been create in the upload folder, i can see debug messsage output after response.write("blabla"), but the javascript function was not invoked. i.e. the preview didn't play.
anyone knows why? is there a timeout or something on response.write so after a period of time it wont work? e.g. 75mb file took longer time to convert than other smaller size file i tried.
thansk
Could be a timeout from the server or caching issue. Or an incorrect uploadifiy property as stated here
after a deeper looking in the source code, and googling around. the problem is narrow down on
DataEvent.UPLOAD_COMPLETE_DATA and firefox issues
someone reported bug
http://bugs.adobe.com/jira/browse/FP-1419
I have designed one web page in asp.net. In that i have used the css file and excel generation button. While i am cliking the button for populating the data from database to excel. It is showing the problem in uploading the css file like that .What will i do the for removing the that error.
For opening the excel sheet I have used the following code that is
Response.ContentType = "application/xls";
Response.AddHeader("Content-Disposition", "attachment; filename=itext.xls");
Is there anything wrong in this?
If I understood correctly, the problem you're having is one I had a long time ago (still in the classic ASP days) where you get an error "missing file" pointing to the css reference when you open the excel file you generated. The workaround I've done at the time was to remove the css reference completely and use inline styles instead.
That will allow you to go home, but if you want a more evolved solution you could make an async request to the server, generate the content there (either in-memory or in a file, depending how big the result is) and then send it back to the client when it's done.