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.
Related
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.
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
I'd like to post file to server by html form below:
<form action="http://localhost:8000/upload/file=1.txt" enctype="multipart/form-data" method="post">
<input type="file">
<input type="submit" value="Send">
</form>
And the HTTP header is below after click button "Send":
Response Headers
HTTP/1.0 200 OK
Date: Tue, 11 Aug 2015 08:35:28 GMT
Server: WSGIServer/0.2 CPython/3.4.3
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=utf-8
Request Headers
POST /upload/file=1.txt HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0)
Gecko/20100101 Firefox/39.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: de
Accept-Encoding: gzip, deflate
Referer: http://localhost:8083/
Connection: keep-alive
Request Headers From Upload Stream
Content-Length 48
Content-Type multipart/form-data;
boundary=---------------------------121841334829646
But it seems the file content can never be posted. Only the "-----------------------------121841334829646--" be posted to server. How can the file content be posted to server by html form?
Thanks!
Form controls can only be successful if they have a name.
<input type="file">
should be
<input type="file" name="my-file">
Arabic user data that was submitted from a website form occasionally ends up Mojibake in our database. A user would type something like:
الإعلان العالمى لحقوق الإنسان
in an input form and the post is received by a server and stored in a database. When we retrieve the message from the database, it reads:
الإعلان العالمى Ù„Øقوق الإنسان
The form is in an embedded iframe page with these tags:
<!DOCTYPE HTML>
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="content-type" />
<!-- other header elements -->
</head>
<body>
<form accept-charset="utf-8" action="https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8" method="post">
<!-- other body elements -->
</body>
</html>
A post generate these request headers
Accept */*
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control no-cache
Connection keep-alive
Content-Length 543
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Host www.salesforce.com
Origin [ -- redacted -- ]
Pragma no-cache
Referer [ -- redacted -- ]
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 FirePHP/0.7.4
x-insight activate
And receives these response headers
HTTP/1.1 200 OK
Date: Fri, 25 Apr 2014 09:15:49 GMT
Cache-Control: private
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
I have no control over the server configuration of the machine serving the form or the server processing the form data.
Is there anything more I can do in the page markup that can prevent the problem? Are there known user agents which would ignore the accept-charset attribute?
Since the character scramble only happens occasionally, what is the best way to try and replicate / isolate the problem?
Thanks!
I am developing a small embedded web server. I want to add parsing of post requests, but I am having a problem with input password fields from Chrome. Firefox and IE work perfectly.
The HTML:
<form action="start.webem" method="post">
<input value="START" type="submit" /><!--#webem start -->
Password: <input type="password" name="yourname" autocomplete="off" />
</form>
From Firefox I get
POST /stop.webem HTTP/1.1
Host: 127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100315 Firefox/3.5.9 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://127.0.0.1:8080/
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
yourname=test
However from Chrome, about 90% of the time, the yourname=test is missing
POST /start.webem HTTP/1.1
Host: 127.0.0.1:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1045 Safari/532.5
Referer: http://127.0.0.1:8080/
Content-Length: 13
Cache-Control: max-age=0
Origin: http://127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Though, occasionally it does work!!!
POST /start.webem HTTP/1.1
Host: 127.0.0.1:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1045 Safari/532.5
Referer: http://127.0.0.1:8080/start.webem
Content-Length: 13
Cache-Control: max-age=0
Origin: http://127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
yourname=test
I cannot find what causes it to work sometimes.
It is a chance that you didn't read the second portion of the data from the socket in your web server. That might describe why sometimes it is working.
Probably because your HTML is so invalid. Fix that and your problems will disappear...
<form action="start.webem" method="post">
<input value="Start" type="submit" />
<p>
<label for="yourname">Password:</label>
<input id="yourname" name="yourname" type="password" autocomplete="off" />
</p>
</form>
To your comment:
HTML isn't technically case sensitive, but you should never ever use uppercase for tag/attribute names. That's just bad practice.
I think the reason it sometimes worked is because you had an open paragraph tag, but never closed it, so Chrome was probably sometimes placing the paragraph outside of your form.