Firefox don't display inline pdf - html

I want display inline a pdf into iframe. It works on Chrome but not on Firefox (latest).
HTML
<iframe src="/3.pdf"></iframe>
Server HTTP response (see content-disposition: inline)
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
vary: Origin
access-control-allow-credentials: true
content-disposition: inline; filename=3.pdf
content-type: application/pdf
date: Fri, 20 Sep 2019 10:56:36 GMT
connection: close
transfer-encoding: chunked
result

You could try to use embed or object tags, like this:
<html>
<body>
<embed src="/3.pdf" width="500" height="375">
</body>
</html>

Related

Why is Firefox showing me a cached version of a page

I have a page the includes an iframe.…
<!DOCTYPE html>
<html>
<body>
<!-- … -->
<iframe
src="/assets/js/pdfjs/web/viewer.html?file=2021-09-12_1200-file.pdf#zoom=page-width"
style="..."
></iframe>
<!-- … -->
</body>
</html>
That includes the following response headers…
HTTP/1.1 200 OK
Date: Tue, 26 Oct 2021 11:02:17 GMT
Server: Apache/2.4.38 (Debian)
X-Powered-By: PHP/7.3.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-DEBUGKIT-ID: 77761443-2882-4882-b0e1-01eea68deded
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2349
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
If I change the file path in the iframe src attribute (e.g /assets/js/pdfjs/web/viewer.html?file=2021-10-26_1200-file.pdf#zoom=page-width - note the new timestamp), and reload the page, the old file is still returned, rather than the new one, despite the Cache-Control: no-store, no-cache, must-revalidate header.
Debugging the requests recevied by the server, I can see…
The parent page is requested and returned with the headers as above (with new Date & X-DEBUGKIT-ID header values), and the correct, updated iframe src value.
The iframe page is being requested with the original filename, rather than the new one (I'm assuming from the cached page).
If I reload using Cmd+Shift+R (to ignore the browser cache), then the correct iframe document is loaded.
What am I missing in this setup that is causing the page to be cached? I thought that the Cache-Control header we have should be sufficient here.
If I add a random query string to the parent page this correctly loads new documents, but I feel this is a hack that should not be needed.
I've also tried adding a Etag header containing a random string that's different for each request, but this seems to have no effect on the browser caching.

What's blocking this IFrame from being loaded?

I am trying to add an IFrame to a page.
The page:
https://www.homedepot.com/order/view/tracking
The code I'm using to add this IFrame:
function createElementFromHTML(htmlString) {
var div = document.createElement('div');
div.innerHTML = htmlString.trim();
// Change this to div.childNodes to support multiple top-level nodes
return div.firstChild;
}
element = createElementFromHTML(`<div id='testing-iframe'>
<iframe src='chrome-extension://zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/index.html'></iframe>
<div>`)
document.body.appendChild(element)
Now, notice the URL starts with chrome-extension://. Different protocol.
On the above homedepot.com page, when I inspect #testing-iframe, I see no IFrame. It's like the browser rejects the element.
On most other websites on the internet, such as https://example.com/, the IFrame element shows on inspection (no content though, as this is a dummy URL).
Please see screenshot:
See, on example.com I do get an IFrame. On homedepot.com I don't.
Another thing to point out, as said earlier this happens when I'm using a different protocol, chrome-extension. But, when I'm using an HTTPS URL such as https://www.texasauto.com/ it DOES WORK, on both pages.
So far regarding the problem.
My question is: What's causing it?
I assume this is some HTTP header.
First I was suspecting the Strict-Transport-Security header.
So, I tried to disable it with another extension, but it didn't fix it.
Then I tried to disable more headers, and also add the Access-Control-Allow-Origin: * header, yet it didn't work.
Any idea what's causing the problem?
Edit: Headers returned by homedepot.com:
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: POST, GET, OPTIONS, DELETE
access-control-allow-origin: http://localhost:8081
access-control-max-age: 0
cache-control: max-age=0, no-cache, no-store
content-encoding: gzip
content-language: he
content-type: text/html;charset=UTF-8
date: Sat, 29 May 2021 22:16:06 GMT
expires: Sat, 29 May 2021 22:16:06 GMT
pragma: no-cache
server-timing: cdn-cache; desc=MISS
server-timing: edge; dur=153
server-timing: origin; dur=75
set-cookie: AKA_A2=A; expires=Sat, 29-May-2021 23:16:06 GMT; path=/; domain=homedepot.com; secure; HttpOnly
strict-transport-security: max-age=86400; includeSubDomains; preload
vary: Accept-Encoding
x-akamai-transformed: 9 153137 0 pmb=mTOE,1mRUM,2
x-application-context: orders-purchases-ui:prod:8080
x-content-type-options: nosniff
x-device-type: desktop
x-frame-options: SAMEORIGIN
x-proto: secure
x-tm-zone: us-east4-a
x-xss-protection: 1; mode=block

Typo3 website. When surfing around the site sometimes the browser shows the html code instead of showing the site

I have a Typo3 website (version 4.5.32). Sometimes (randomly) when I'm surfing around my website the browser shows the html code instead of showing the webpage.
For example it shows:
HTTP/1.1 200 OK
Date: Thu, 12 Feb 2015 11:36:29 GMT
Server: Apache
Set-Cookie: fe_typo_user=f4b8445b0719bd7490dcde98e7d8ff5b;
path=/; domain=.<my_domain>
Vary: Accept-Encoding,User-Agent
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
bfee
<!DOCTYPE html>
<html lang="es-ES" xmlns="http://www.w3.org/1999/xhtml">
...
</html>
<!-- Cached page generated 12-02-15 12:35. Expires 13-02-15 12:35 -->
<!-- Parsetime: 0ms -->
0
when it should show the webpage.
Another example:
HTTP/1.1 200 OK
Date: Thu, 12 Feb 2015 11:41:19 GMT
Server: Apache
Set-Cookie: fe_typo_user=fd0199b1f48b719c097ef19418f18397; path=/; domain=.<my_domain>
Expires: 0
Last-Modified: Thu, 12 Feb 2015 11:41:19 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: be_typo_user=71e6061cabf0d60a03739493561b67d9; path=/
Vary: Accept-Encoding,User-Agent
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
9395
<!DOCTYPE html>
<html lang="es-ES" xmlns="http://www.w3.org/1999/xhtml">
...
</html>
<!-- Cached page generated 12-02-15 12:37. Expires 13-02-15 12:37 -->
<!-- Parsetime: 111ms -->
0
Thanks.
The extra character before the actual output (bfee, 9395) are the lengths of the following block of data. The header Transfer-Encoding: chunked also indicates that the output is cut into blocks (chunks).
All user agents (browsers, etcetera) must support chunked transfer encoding. Perhaps there is some proxy in between that ruins the experience? Anyway, it's the webserver that decides to use this transfer encoding and not TYPO3.
The only thing inside TYPO3 that could ruin things is when the content is retrieved using t3lib_div::getUrl(). This function only supports chunked data if you have cURL activated in the installation.

MIME Type Warning in Google Chrome Console

I generate a captcha image (as a .bmp) on the fly with a server side script (.asp).
It is included in a page as follows:
<iframe id="commentCaptcha" height="20px" width="50px" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" src="/inc_captcha.asp">
Everything works as it should.
The problem/Question is that I get the following warning in the google chrome console:
Resource interpreted as Document but transferred with MIME type image/bmp: "/inc_captcha.asp".
Here are the actual raw headers returned from the server:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: image/bmp
Expires: Sun, 13 Jan 2013 03:11:36 GMT
Server: Microsoft-IIS/7.5
Date: Sun, 13 Jan 2013 03:12:36 GMT
Connection: close
Is there any way I can prevent this warning?
Setting the source of the iframe to a non-document mine-type is a little strange and not really the usual way of doing it.
Instead the iframe should have the src set to a text/HTML document, your image being an <img> within that document.
If it's just the image you're after, use the <img> tag in the parent document and dont use an iframe at all.

Website is displayed as HTML-Code instead of rendered HTML - indeterministic

I have a problem with a website, where sometimes only the HTML text is displayed in the browser window, instead of the rendered HTML page. This happens sometimes in all browsers.
Example URL:
http://www.starkl.at/view/p-1258/Newsletter---Gartentipp/
The HTTP request headers from IE9 are (Cookies are not shown):
GET http://www.starkl.at/view/p-1258/Newsletter---Gartentipp/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://www.starkl.at/view/p-1931/Service/
Accept-Language: de-AT
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
DNT: 1
Host: www.starkl.at
Pragma: no-cache
The HTTP response headers are:
HTTP/1.1 200 OK
Date: Wed, 19 Sep 2012 07:43:49 GMT
Cache-Control: no-cache, no-store, must-revalidate, proxy-revalidate
Content-Type: text/html;charset=UTF-8
Content-Length: 21160
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Also the content length (in bytes) seems to match.
It's a Java 6/7 application running on a Tomcat 6/7, with an additional httpd 2.2.x in front.
Any idea what the problem could be????
Thanks in advance!
If the browser writes the code and not renders it is because it's being told to do so, probably your app is returning html encoded in a way that browser thinks it's plain text.
Open tools, options, email, email options, then uncheck "Read all standard mail in plain text." This is for Outlook 2003 so your version, if not 2003, might be slightly different.