Suggesting filename on right click save as - http

I have a site that allows file uploads and saves them with a uuid filename on the server. When a user right clicks to "save as" and download the file the odd looking uuid filename is shown in the download dialog. Is there anyway possible to show the original filename (which is saved on upload)? I've seen several post like this one but can't seem to get it to work on FF 3.6 or Google Chrome (which I need to support)...
Any ideas?
PS: I'm working with javascript and a python back-end, if that helps...

You need to use a Content-Disposition header, set to attachment and supply a filename.
content-disposition: attachment; filename=myfilename.ext
I'd be more specific, but you did not indicate language or platform.
Update:
In python it would be
response.headers['Content-disposition'] = 'attachment; filename=filename.ext'

Related

Open PDF in browser instead of downloading it

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";
}
})

In mpdf to Output a pdf file to a Browser

I am trying to view the pdf file created using mpdf.
On using the command as
$pdf = $mpdf->Output('mep.pdf','I');
the pdf gets downloaded rather.
Although, I: send the file inline to the browser. The plug-in is used if available. The name given by filename is used when one selects the "Save as" option on the link generating the PDF.
I would like to view the pdf in the browser and depending on the user choice to download it, print it or just view it and exit.
Kindly help. Thanks.
It depends on the browser whether it can and will display PDF files inline. But to help it a little you should at least tell the browser that it's a PDF file. You can do this by sending a content-type header:
header('Content-Type: application/pdf');
This line should be executed before sending the PDF contents.
You can use this. May be it will help you.
include file:
include_once './mpdf/mpdf.php';
create object of mpdf:
$pdf =new mPDF("","A4","","",10,10,10,10,6,3);
$mpdf->WriteHTML('Text which you want in PDF file');
$pdf->Output('filename.pdf','I');
Still not able to view file:
define content type of header
header('Content-Type: application/pdf',charset=utf-8');

force user to download rather then open xlsx file in browser

We have some users who when they open an excel file on my website it takes ages. If they simpely Save as and then open it's quick.
They have the same issue on other sites so it's a problem on their side.
However is there a way to force the browser to only offer save and not offer open?
As noted here:
Is there a way to force the user to download a file from a href link rather than to open it in a browser window?
and here:
Forcing to download a file using PHP
I'm currently using:
Response.ContentType = "application/ms-excel";
Response.AddHeader("content-disposition", "attachment; filename=Report.xlsx");
Response.AddHeader("Content-Length", new System.IO.FileInfo(fileName).Length.ToString());
But this is still offering the open option.
Is there a way to force this or is it simply dependent on the users browser settings.
Just send a different Content-Type (application/octet-stream):
Response.ContentType = "application/octet-stream";
This way the browser doesn't recognize the format and just proposes to save the file.
--- EDIT ----
Today, I got to know another header field, that probably fixes your problem:
"X-Content-Type-Options: nosniff"
Description: "The only defined value, 'nosniff', prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions.[31]"
(http://en.wikipedia.org/wiki/List_of_HTTP_header_fields)
Although the Question is quite old I am going to answer...
For IE8/9 and Chrome this worked for me:
Response.AddHeader("X-Download-Options", "noopen");

Firefox response.redirect not working for files

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.

Node JS Proper Content-Type for responses

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);

Resources