We have a web application which offers a file named L_2804071.key for download. The download works fine in Internet Explorer and FireFox but in Chrome it "loses" the filename and chrome does not seem to recognize the filename in the content-disposition header.
Here is the full header (identical in both browsers):
content-disposition: attachment; =?utf-16le?B?ZmlsZW5hbWU9TF8yODA0MDcxLmtleQ==?=
I don't know if this helps but if you decode =?utf-16le?B?ZmlsZW5hbWU9TF8yODA0MDcxLmtleQ==?= you get Wfilename=L_2804071.key which looks weird. Not sure where the "W" comes from but IE seems to work with it and downloads a file named L_2804071.key.
Fix the web application to return a Content-Disposition header field that follows the spec, your example is invalid (for starters, there's no "filename" parameter). Note that your example appears to use RFC2047-style encoding, which in general isn't used in Content-Disposition.
See http://greenbytes.de/tech/webdav/rfc6266.html for details.
Related
There are some old questions regarding this topic, but the issue I'm facing is just some days old so thought to create a new thread.
I am using the content-disposition inline combined with filename to open a PDF file directly in Browser.
content-disposition: inline; filename="MyFile.pdf"
Until a couple of days ago it was working fine in Chrome and Firefox, (I know that in old IE versions the filename parameter wouldn't work in inline), PDF was opening in browser with the correct (provided) filename.
Now it seems like the filename parameter isn't working anymore even for Chrome and Firefox. The PDF is opened correctly but created with a name from the last part of the URL, which in my case is just pdf (https://.../pdf).
If I switch to attachment instead of inline the filename works fine, file gets downloaded with the correct filename. Issue is that I need to open the file in browser and not download it.
Is inline with filename not anymore possible in Chrome and Firefox?
I am facing very similar problem lately.
Strangely, when making a POST request for PDF document, the filename is ignored. But if I make a GET request, everything works like before. PDF is shown correctly and SaveAs also works with correct filename.
I ended up making a redirect on the server side, so the last request is a GET.
Another thing I noticed is, when the user clicks on the Download (Save As) button in the browser's PDF viewer, the server gets another request for the document and serves the content again. The Print command however does not make another request and prints the content already in the PDF viewer.
Hope this info helps, even if only to let you know, you're not the only one with this problem.
Edit:
It turned out, that POST and GET requests did not have anything to do with the problem. The problem was Cache-Control: no-store header that prevented the browser to store the PDF content and forced it to make another request for the PDF content at Save As command. The POST command was not formed correctly the second time which resulted in "Network Error".
I removed no-store from the header and now everything works fine.
The new header looks like this:
Cache-Control: no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
I have found that in my environment, URLs containing basic authentication do not allow inline display of pdfs.
In IE9 and IE10 also, Base64 data Uri is not working in the object tag to load the pdf. It is showing a message below "Access Denied".
<object id="objPdf" data="data:application/pdf;charset=utf-8;base64,{myValue}" type="application/pdf"></object>
Any idea on this?
IE doesn't support the data protocol. Per the documentation, the only supported elements/attributes are the following:
object (images only)
img
input type=image
link
CSS declarations that accept a URL, such as background, backgroundImage, and so on.
Besides, there's also a "IE 10 treats blob URL as cross-origin and denies access" bug filled against IE, still open and active.
I just ran into the same issue when trying to serve CSV data (data:text/csv;charset=utf-8,...)
This is an old post but if someone comes across this on a Google search the solution is that you need to have a URL or API endpoint that will return your pdf data, then you put the address to that in your object's data attribute.
<object data="/api/pdf"
If your pdf is generated by information on the page then you can send that info to the API endpoint in the querystring.
This only happens in Chrome, works great in Safari. Chrome is complaining that duplicate content-disposition headers are being received. When I upload a file to S3 I set the content disposition so that I can name the file upon download and also ensure it gets downloaded as an attachment (not inline).
Here's what I'm getting specifically:
When I experienced this error it was because I had something like this:
Response.AddHeader("Content-Disposition", "attachment;filename=file,withcomma.pdf")
Chrome is interpreting this as two Content-Disposition headers: "attachment:filename=file" and ",withcomma.pdf".
Wrapping the filename in quotes resolved the issue for me:
Response.AddHeader("Content-Disposition", "attachment;filename=\"file,withcomma.pdf\"")
I've seen your question and I've just solved mine, though my code is asp.net. I started getting this error today, Chrome must have added some stricter handling of headers. Anyway, my bug turned out to be the part where I set the content-disposition header.
Instead of
Response.AppendHeader("Content-Disposition", "attachment,filename=abcdxyz.pdf")
I changed it to
Response.AppendHeader("Content-Disposition", "attachment;filename=abcdxyz.pdf")
The comma seemed to cause some kind of problem, switching to a semi-colon seems to fix it. It's now working fine for me, but I should mention that I am not familiar with Amazon S3 (at all) so maybe I'm waaaay off, but since it has just worked for me, maybe it'll work for you.
Duplicated header error on Chrome is a bug with the HTML header: "Content-disposition: attachment" when the filename comes with comma(s).
The solution here, we just add double quotes (") between filename as example:
Response.AddHeader("Content-Disposition", "attachment;filename=\"file,withcomma.pdf\"")
And this solution works for all browsers (as I tested on IE11, Chrome, Firefox)
Original code:
header("Content-Disposition: attachment; filename=$displayname");
changed:
header('Content-Disposition: attachment; filename="'.$displayname.'"');
How do you make an MP3 link download instead of play "in-browser"?
I tried changing the target to blank, but that just opened the player in a new window.
You can't do this by modifying the link. You will have to have the HTTP server that serves the file send a Content-Type of "application/octet-stream". Presumably it is sending the type "audio/mpeg", which is hinting to the browser that it is MP3 content. Without the capacity to alter this header, you can't achieve this.
If your server supports PHP, create a PHP script called "getfile.php" (or similar) that takes a parameter of a file ID or file name. Set the content-type and content-disposition headers within the script to force a download prompt.
See: http://webdesign.about.com/od/php/ht/force_download.htm
Lots of solutions here. Here's the basic idea:
Use Javascript to make a (ajax) request to the server
When the request is received, run a script
This script redirects your browser temporarily to a new page
The new page has a few headers telling your browser to expect a file attachment, and what kind of attachment it is
The "save as" dialog pops up and your original page is still onscreen
I could be wrong, but I've seen people with the same problem before just with other file types, they used the code below:
<FilesMatch "\.(?i:mp3)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
Hope this works for you!
For quite some time (Chrome 14+, Firefox 20+, Edge 44+) it is possible to use the download attribute on same-origin links to force download behavior even when the server doesn't supply a Content-Disposition header on the link target.
Without access to the server generating the HTTP responses, the browser gets to decide what to do with different types of responses. usually the only files a browser will download are things like .zip files which it cannot display.
I have a very strange problem:
I use xsl to show an html picture where the source is defined in the xml file like this:
<pic src="..\_images\gallery\smallPictures\2009-03-11 אפריקה ושחור לבן\020.jpg" width="150" height="120" />
[the funny chars are Hebrew- ;) ]
Now comes the strange part:
When testing the file locally it works on Firefox and Safari but NOT in IE and opera. (file://c:/file.xml)
Next I send the file to the host throw FTP (nothing more)
Than it suddenly works with all browsers when calling the page from the host: (http://www.host/file.xml)
The question is how can the server send the xml file to my browser in a way that my browser can read, while the same browser cannot read the same file stored locally ?!
I always thought that both HTML(xml) and pictures are sent to the client which is responsible to load the page - so how come the same files works for my webhost provider and not for me?
And what makes it totally strange is that IE is not alone - Opera joins it with this strange behavior.
Any ideas?
Thanks alot
Asaf
When you open the file locally, there is no server to serve up HTTP headers. That's a big difference at least. Try examining the coding the browser thinks the page is in, when it's opened manually from disc, and when served over HTTP.
If headers are set correctly by either your script, or the server, then that is likely why.
This is most likely an encoding problem. Try to specify the encoding explicitly in the generated HTML page by including the following META element in the head of the page (assuming that your XSLT is set to generate UTF-8):
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
...
</head>
...
This tells the browser to use UTF-8 encoding when rendering the page (You can actually see the encoding used in Internet Explorer's Page -> Encoding menu).
The reason why this works when the page is served by your web server is that the web server tells the browser already what encoding the response has in one of the HTTP headers.
To get a basic understanding what encoding means I recommend you to read the following article:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets
..\_images\gallery\smallPictures\2009-03-11 אפריקה ושחור לבן\020.jpg
that's a Windows filepath and not anything like a valid valid URI. You need to:
replace the \ backslashes with /;
presumably, remove the .., if you're expecting the file to be in the root directory;
replace the spaces (and any other URL-unfriendly punctuation) with URL-encoded versions;
for compatibility with browsers that don't properly support IRI (and to avoid page encoding problems) non-ASCII characters like the Hebrew have to be UTF-8-and-URL-encoded.
You should end up with:
<img src="_images/gallery/smallPictures/2009-03-11%20020/%D7%90%D7%A4%D7%A8%D7%99%D7%A7%D7%94%20%D7%95%D7%A9%D7%97%D7%95%D7%A8%20%D7%9C%D7%91%D7%9F%10.jpg"/>
There's no practical way you can convert filepath to URI in XSLT alone. You will need some scripting language on the server, for example in Python you'd use nturl2path.pathname2url().
It's generally better to keep the file reference in URL form in the XML source.
#Asaf, I believe #Svend is right. HTTP headers will specify content type, content encoding, and other things. Encoding is likely the reason for the weird behavior. In the absence of header information specifying encoding, different browsers will guess the encoding using different methods.
Try right-clicking on the page in the browser and "Show page info". Content encoding should be different when you serve it from a server, than when it's coming straight from your hard drive, depending on your browser.