I am using an <iframe> to display a text file:
<div class="document-view">
<img src="img/302.GIF" />
</div>
$(window).load(function () {
<s:if test="extention.equalsIgnoreCase('txt')">
element = '<iframe class="iframe" src="/dmsrepo/<s:property value="docLocation"/>" />';
</s:if>
$('.document-view').html(element);
});
When I inspect element in the browser I can see the file location.
<iframe class="iframe" src="/dmsrepo/Legal Doc Type/LegalDocType_123456789_1.0.txt" />
But the text file is getting downloaded in Chrome, Firefox and IE.
How to resolve this issue?
EDIT: you can reproduce the behavior in the following fiddle, that strangely affects only Firefox, for every page load after the first one.
Simply open the page, then press Run.
Note: it affects also the first load if Firebug Net module is activated.
This is the issue with the file. it is not formatted as html. because it has some special unicode (eg) characters at end of file read. if text response has special character like that. it failed to parse response as html embedded in iframe.
you can check this example :
<iframe src='http://humanstxt.org/humans.txt' /> </iframe>
because browser understands only html. Change your file extension to .html
or use server side language like php and using file_get_contents() function, you can display text file to browser.
to display file add below line(s) in .htaccess
AddType text/plain .txt
AddType text/plain .log
This is signal Firefox that you don't have to download the file instead view file as plain text.This technique can be applied to all the files that you need to view instead off download.
The Content-Disposition response header could be the culprit. If set to attachment; filename="..." then the file will download. If set to inline then it can displayed in the Web page.
If you are serving these files from Amazon S3, you can add Metadata to the file with the Key=Content-Disposition and the Value=inline.
Note: the default value is typically inline.
Related
We have a internal website where we have some links to pdf documents hosted on the webserver. If i open Chrome Dev-Tools(F12), and inspect the link and add an embed with the same pdf document, it will rather download the file instead of showing it. I have tried with embed and iframe, but i still get the same problem.
Original code:
<a id="id2239" href="http://example.com:8080/client/attachment/filename.pdf" class="act01">filename.pdf</a>
Screenshot:
Code that we would like to work:
<a id="id2239" href="http://example.com:8080/client/attachment/filename.pdf" class="act01">filename.pdf</a>
<div class="fgh"><embed id="fgh" src="http://example.com:8080/client/attachment/filename.pdf" type="application/pdf" width="400" height="400"></div>
Screenshot:
As you can see, it actually downloads the document instead of showing it in the screenshot above. Just shows a white space.
Code that works with another document:
I just found a pdf document on google, and put it into the tag, and it works. It shows the document in the embed, and doesn't download the document instead.
<a id="id2239" href="http://example.com:8080/client/attachment/filename.pdf" class="act01">filename.pdf</a>
<div class="fgh"><embed id="fgh" src="http://infolab.stanford.edu/pub/papers/google.pdf" type="application/pdf" width="400" height="400"></div>
Screenshot:
Question:
Why is the two examples different? Why does the internal document download, but the external document show embedded in the page?
How do i make it work with the file on our webservers as well?
Edit:
Screenshot of the pdf documents headings.
It depends on the content type in the response header. You may check if your web server sets proper header information, e.g. Content-Type: application/pdf.
"Chrome Dev-Tools(F12)" -> Network Tab, check the response headers.
I was facing the same issue. In my case the Content-Type of my files was "binary/octet-stream". I had to manually change it to "application/pdf" to resolve it
Use the <object> tag to embed PDF files in html:
<object id="fgh" data="http://example.com:8080/client/attachment/filename.pdf" width="400" height="400"></object>
I have saved a complete HTML page from a server using Chrome.
When I load the local file again in Chrome, the SVGZ images do not render and instead shows a broken image icon.
Double checking the file and loading again from the original server, I find that the SVGZ loads just fine
If I load just the local image file on its own, I get prompted to save the image
If I edit the local image filename extension to .SVG, and load on its own, it renders just fine
If I then edit the HTML file to refer to the renamed file with the .SVG extension, then the entire page and image all loads correctly
I know this is not strictly a programming issue, but in doing a lot of searching, I have found more closely related answers here on StackOverflow than on say AskUbuntu.
This answer provides the best clue I have found thus far:
Chrome not rendering SVG referenced via <img> tag
I came here because I had a similar problem, the image was not being
rendered. What I found out was that the content type header of my
testing server wasn't correct. I fixed it by adding the following to
my .htaccess file:
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
So I am guessing that the problem lies somewhere with:
when loaded from the server, the content type is correctly specified
when loaded from my local file, the content type is NOT correctly specified
Is there any way to resolve this ?
Can I "mimic" the .htaccess mime type and encoding by changing a Chrome setting ?
Any advice is appreciated.
I created a test HTML file with an <img> that loads a .svgz file. It worked okay (Chrome on Win7).
Check that your .svgz file is actually a gzipped SVG file, and not something else. For instance I suspect that it is actually a normal SVG file but with a ".svgz" extension. That will fail in the way you describe.
I'm trying to get this simple code to work:
<a href="#" target="_blank" style="display: inline-block;">
<object data="icons/chrome.svg" type="image/svg+xml" style="pointer-events: none;">
fallback text
</object>
</a>
When I use
data="http://images3.wikia.nocookie.net/__cb20120330024139/logopedia/images/d/d7/Google_Chrome_logo_2011.svg"
it works. However when I save that exact file onto my own server and reference it as above, it just shows the fallback text in Firefox. In Chrome it downloads the file when I open the page (which proves that the file link is correct).
Anyone know what's going on here?
I can think of four possibilities:
Your server is using the wrong MIME type for SVG images. (Can be fixed by adding AddType image/svg+xml svg to your .htaccess file; other methods discussed here)
You saved the SVG file somewhere else and it doesn't exist at icons/chrome.svg. (Try navigating straight to the SVG file at icons/chrome.svg. Does it display in your browser?)
You saved the file with insufficient permissions, resulting in your web server being unable to access the file. (Can be fixed by navigating to the icons directory and typing chmod 0644 chrome.svg at the command line prompt.)
The file you downloaded from nocookie.net isn't actually an SVG file at all. (Try opening it inside a text editor.)
I was experiencing the first of the problems described by #r3mainer.
On my lighttpd server the problem was caused by the missing
".svg" => "image/svg+xml",
line in the mimetype.assign section of the lighttpd configuration file.
My iframe tag look like bellow
<iframe width="100%" height="100%" src="'+file_url+'" frameBorder="0"> <p>Your browser does not support .</p></iframe>
file_url = store/ASDFVASDFADSFACASDFCDDF.doc
file_name = my word.doc
when i click on the iframe open link file download with incorrect file name.(doc file download with ASDFVASDFADSFACASDFCDDF.doc file name). how can i download file with real file name using iframe?
The iframe element can't do that, but you could put this in a .htaccess file in the 'store' directory :
<FilesMatch ".doc$">
Header set Content-Disposition "attachment; filename=myword.doc"
</FilesMatch>
Note that I'm assuming Apache here, but most webservers have a similar function
In modern browsers that support the download attribute, you should be able to specify in the following way:
Download
The nice thing is, this will also trigger a forced download behavior in the browser.
Alternatively, you could pass your download through a PHP script to set the filename to be served in the headers, something like this:
<?php
// We'll be outputting a PDF
header('Content-type: application/pdf');
// It will be called downloaded.pdf
header('Content-Disposition: attachment; filename="downloaded.pdf"');
// The PDF source is in original.pdf
readfile('original.pdf');
?>
This has nothing to do with HTML. You cannot do it.
The web server needs to send a "Content-Disposition" header. How to make your server do that depends what software is running on the server.
Alternatively... Just change the URL to this (and obviously move the file on the server):
store/ASDFVASDFADSFACASDFCDDF/Filename.doc
IE7 fails to display any contents in dynamically generated url inside the <object> element. Here's an example for loading pdf documents:
<object data="http://localhost:8080/Documents/Query?Id=document123&Session=1510" width="600" height="400"></object>
The above code will fail to load, however, if I copy and paste the url into the browser's navigation bar, the pdf document will load just fine. If I then manually save the pdf file and replace the object tag with the code below, it works just fine.
<object data="document123.pdf" width="600" height="400"></object>
Is there a work around for this?
It's hard to be sure exactly what the problem is without knowing more about your development platform and possibly seeing some of the code for Query. But my guess is that it's down to the mime type that the server is presenting.
You should send the mime type header as application/pdf.
Just came accross this issue myself.
I don't know if yours was the same problem as mine but if you are using the following:
Response.AddHeader("Content-Disposition", "attachment; filename=...
Remove it, keep the content-type as "application/pdf" but don't assign a disposition, that way it will be processed as an outright file and not as an attachment to be downloaded.