We're using the HTML5 Application Cache feature:
<html manifest=".appcache">
...
</html>
When returning users navigate to this application they will already have all static files cached and the application is therefore loaded without network requests.
Once the application is loaded it will make AJAX requests to load dynamic content, and the browser will check whether the Application Cache manifest is outdated and possibly download a new version of the application in the background.
Many of our users are accessing this application over insecure connections (HTTP, not HTTPS).
We're in the process of introducing HTTP Strict Transport Security (HSTS) on the servers that host the application.
Implementing HSTS means that our servers will handle requests like this:
If the request is insecure (HTTP only), then the server will respond with HTTP status 301 and a Location header that redirect to the requested URI but changing scheme to https.
Otherwise; if the request is secure (HTTPS) the server will process it as normal but decorate the response with a Strict-Transport-Security header.
So, when a new user open up our application over HTTP they will be redirected to HTTPS instead and then the application cache manifest is installed using the secure location. That's perfect.
However, a returning user (over HTTP) will NOT be redirected to the secure location (because they already have a cached version on the insecure location). The application cache manifest won't load (since it's a redirection). So returning users are stuck with the application version they had cached and they're stuck using HTTP which is no longer allowed. This is very bad.
We need to come up with a way to transition returning HTTP users to the HTTPS version. How would be best do that?
The way I see it there are two problems:
The browser cannot fetch the application manifest (because it is a redirection). It is therefore unable to upgrade the application to a new version.
We could perhaps overcome this problem by configuring our servers to allow /.appcache to be served over plain HTTP.
Even if we do that, the application will still be accessed at the HTTP location (since that what's cached by the manifest)
To workaround that, we might have to implement some kind of javascript logic that changes the scheme of document.location.href to HTTPS.
I don't like this approach, but it's the only one we've got at this point.
We settled on the following solution to this problem:
When server receive an insecure request to get the application cache manifest (/.appcache in our case), then a 404 response is returned instead of the normal HTTPS redirect (301).
Getting a 404 causes the cached manifest to be stale and the browser will therefore attempt to reload the application on the next refresh, which will cause it to fetch index.html and be redirected to the secure location.
Related
I search everywhere I found 0 information about this specific redirect.
I have app that I need to use "HTTP" to function, recently chrome started to redirect my app to HTTPS automatically, and If I put HTTPS to HTTP code in my app it cause infinite loop.
My app is not on the HSTS preload domain list, my app and server have no redirect code to HTTPS.
Request URL: http://4444.com/z.txt
Request Method: GET
Status Code: 307 Internal Redirect (from disk cache)
Referrer Policy: strict-origin-when-cross-origin
Cross-Origin-Resource-Policy: Cross-Origin
Location: https://4444.com/z.txt
Non-Authoritative-Reason: DNS
This does not happen on any other browser other than chrome.
Does that mean chrome is targeting my host's dns to make sure all website hosted on the DNS is HTTPS?
If yes I think this is very bad move from google as I can't find any announcement by google that they will start forcing https on websites. This could break many non https sites without prior warning.
If not what can I do to fix this issue?
Thanks
I encountered the same problem just like you, and that situation didn't happen all the time, sometimes when I open another window as incognito mode, the redirect disappeared!Sooooo Annoying:(
And I just tried another way, it seemed to work fine with me!
go to : chrome://net-internals/#dns, and click Clear host cache , then refresh your page, the redirect will be gone!
Even if the "Always use secure connections" (chrome://settings/security) is disabled, chrome will still try to use HTTPS if it finds HTTPS records in DNS, as per #dns-https-svcb flag - "Support for HTTPS records in DNS" (chrome://flags/#dns-https-svcb) - which is enabled by default.
This causes the loop leading to the ERR_TOO_MANY_REDIRECTS with Non-Authoritative-Reason: DNS.
Either remove any HTTPS record from the host zone file or disable the aforementioned flag from chrome.
Did you access websites using VPN? VPN server seems able to force http to https
I am facing an issue with my hosted project.
The request with link :- http://......./api_tester.html works fine and
provides results, but, it gives CORS 'Access-Control-Allow-Origin' Missing
when the api_tester.html file is accessed via the browser directly.
The URL for the file in the browser is file:///E:/workspace_windows/api_tester.html
Kindly suggest.
It seems you are trying to open the file directly from desktop, hence it is picking its protocol file:// protocol. Use either complete url starting with HTTP or run from any web server. Secondly error you stated means you are trying to access the page hosted on another domain and this usually happens when you do XHR requests to domain other than the one where your file is hosted.
You can add header "ACCESS-CONTROL-ALLOW-ORIGIN" to the file you are trying to access to allow all requests to be accessible from all different domains.
In our current site all our http traffic is redirected to https using permanent redirects(301).
Now I want to redirect all https traffic to http and for some pages(like checkout, login) it will be http to https
I have done the configurations in nginx, and they work fine (tested with adding entry to /etc/hosts) only when browser cache is cleaned.
Since browser caches all the redirects and it is not possible to tell users to clean browser cache, I am exploring of ways to do this project.
What is happening is when I hit http version it gets redirected to https version due to browser caching. Since, in my configuration I have redirected to http version, the request gets redirected to http and redirections enter infinite loop.
The ways I can think of are:
Some how nginx detects that there is a second time request to https and serves him https content insted of redirecting to http. I know this is against the principle of http, but I was wondering if it is possible. Please let me know if it is possible this way. I will be serving both https and http to a browser but when cache is cleared eventually it will work fine with no further changes required.
If I change A record of DNS, will it cause the browser cache to be clean. If that happens I will go for it.
I keep both http and https versions for a while with no redirects and after one month or so, do the redirections.
How do you tell if a site is an HTTP:// site or an HTTPS:// site? I am just starting to learn some of the more fundamental things about internet security. When you put up a web site is there a special way that you have to set up the html format in the .html files so that the site is secure or is this something that can be purchased from the site provider were you host the web site.
This seems like and easy thing to do but even on stackoverflow what it type in is
stackoverflow.com/questions/ask
There is no HTTP or HTTPS in front of the internet address. Is this implied or is there a way to toggle this on an off in the tools?
HTML Code:
<html lang="en">
<head>
<title>Test Title</title>
</head>
<body>
//...code goes here...
</body>
</html>
Is there something that goes in the HTML that determines whether the site is secure or not? Or is this an option on each page when you host the site.
How do you tell if a site is an HTTP:// site or an HTTPS:// site?
By looking at the URL
This seems like and easy thing to do but even on stackoverflow what it type in is
If you type in something that looks like a URL with the scheme missing, then browsers will assume you intended to put http:// in front of it.
Most browsers will hide the http:// part from the address bar for non-SSL sites.
When you put up a web site is there a special way that you have to set up the html format in the .html files so that the site is secure or is this something that can be purchased from the site provider were you host the web site.
To use SSL you need to have an SSL certificate and the web server needs to be configured to use it.
Beyond that, everything comes down to how the server is configured. You could have different sites hosted on http and https, or the same site, or redirect from one to the other, and so on.
Is there something that goes in the HTML that determines whether the site is secure or not?
No. SSL is dealt with at the transport level, not the document level.
Or is this an option on each page when you host the site.
You could configure a server to redirect the URLs for some pages to HTTPS and some to HTTP. This was typically done to save on CPU power for pages where security wasn't needed. Today, CPU power is much cheaper, so it is normally better to use SSL by default.
To make a site secured (an HTTPS) site you need a certificate and add the proper binding that means including a port and protocol by default https uses port 443 and NO, none of those configurations at server level will affect the files serve like your .html files.
HTTP means Hypertext Transfer Protocol. The "S" is Secure.
There is no special definition you can define to ensure a secure HTTP connection.
SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral.
These certificates can be purchased from companies that provide them. This essentially encrypts any data transferred between the server and person it is responding to.
In short, this is determined by the browser, and different browsers have different strategies.
When you visit a site, such as www.abc.com, different browsers will use different default protocols.
Microsoft Edge will first use http to connect to port 80 of the server. If the server is set to redirect, it will send a 301 move permanently message to allow the client to reconnect to the site using https.
But the new version of chrome will directly use https to connect to the site (port 443), if the connection fails, then connect to http (port 80).
https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html
Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol. HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.
Is there is any way to find out from where an image is loaded to browser. From server / browser cache or proxy cache etc. I am using asp.net MVC
Here is my take on this:
1) Server: Default; the request can be seen on the Fiddler.
2) Browse cache: No request is sent so Fiddler will not show a request to the server. Also if the resource is changed on the server, it is not updated on the client.
3) Proxy/Cache server: It is tricky and not always reliable. It looks like the server but you will most likely see X-cache or similar cache related and sometimes non-standard headers, depending on the proxy or the cache server used.