I set up jenkins in my local computer and try to visit it. I just put http://127.0.0.1:8080/ in the address bar of Chrome and push the Enter button. Because I have not loggin, it returns a response with status 403, but empty response body.This is the first line in below network screenshot.
Then after this, it returs another http response with login forms, the second line in below netwrok screenshot.
As I understand, there is no redirect function inside http status 403. How does it return two response?
I find out the inner reason. Hope it can help anyone who is also curious about this.
Although the response http status is 403, but it also returns html content as below.
HTTP/1.1 403 Forbidden
Date: Fri, 03 Jun 2022 13:05:20 GMT
X-Content-Type-Options: nosniff
Content-Type: text/html;charset=utf-8
X-Hudson: 1.395
X-Jenkins: 2.332.3
X-Jenkins-Session: 48f49ae2
Content-Length: 548
Server: Jetty(9.4.43.v20210629)
<html>
<head>
<meta http-equiv='refresh' content='1;url=/login?from=%2F'/>
<script>window.location.replace('/login?from=%2F');</script>
</head>
<body style='background-color:white; color:white;'>
Authentication required
<!--
-->
</body>
</html>
In the response, it contains http-equiv='refresh', the browser receives this command, and it redirctes the page.
Related
I have a webserver since my main HTML page does not contain a webicon, (just a basic template)
"HTTP/1.1 200 OK"
Content-Type: text/html
Connection: close
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Title of the document</title>
</head>
<body>
<h1>This is a heading</h1>
<p>This is a paragraph.</p>
</body>
</html>
Both chrome and Mozilla will also send an additional HTTP request :
GET /favicon.ico
I would like to respond to this request by sending a PNG file, problem is the tab icon is not showing up even If I successfully return to the /favicon.ico request.
Ny response to GET /favicon.ico looks like this:
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGQAAAB0CAYAAABzNJfPAAAABGdBTUEAALGP....
But the icon does not show up on the tab bar. I am getting this:
What I was expecting is for the icon to show up in the tab like this
You might say just include the icon in the main HTML. But that would be "cheating" since what I am setting out to do is to handle a /favicon.ico requests from browsers. If I do that I would just be avoiding the issue, not addressing it
Your content-type header is set to text/plain which makes the browser read it as plain text, not an image. Try setting it to image/png. Also, don't send the image as base64, just send the raw image. I'm not sure what web server you are using so I can't help you with how to send it as a raw image.
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 have a logon link on my homepage that shows when a user is logged out. When they are logged in it instead shows the link to my dashboard. This is handled server side and come from server in the HTML.
I have an Issue when a user follows this sequence:
loads homepage
clicks login
logs in and is directed to dashboard
clicks home link and is brought back to homepage
When they do this the homepage is loaded from local cache and still displays the log in link instead of the dashboard link.
If I hit refresh in the browser then it loads the new page with correct link.
I have tried adding the following headers to the HTML:
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">
But this doesn't help.
In network tab this is the response headers when loading th page logged out:
accept-ranges: bytes
content-encoding: gzip
content-length: 10290
content-type: text/html
date: Sun, 19 Sep 2021 03:29:38 GMT
etag: "6146829a-2832"
last-modified: Sun, 19 Sep 2021 00:21:46 GMT
referrer-policy: no-referrer-when-downgrade
server: nginx/1.19.5
I am testing in latest version of chrome.
Why does clicking home link load from cache instead of getting the new page?
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 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.