If we enter the domain name manually like "xyz.com" then it automatically picks "HTTP" instead of "https' on google page speed insight.
This seems to be a bug because this behavior is across all sites.
And then google page speed insights show lower score thanks to the HTTP version.
This is not a bug.
When you enter a domain name without http or https in your URL bar in your browser it will try http first.
This carries with it a performance hit that should be considered as part of any speed testing.
Depending on how you do your redirects this can be anywhere from 10ms to 100ms and so needs to be considered.
Where the problem lies is that it should actually strip https first, as if you enter https instead of http it will not take the redirect into account on your final score.
Always enter your domain without http or https for the most accurate picture of your site performance.
The test for 'too many redirects' does not care what you enter, the above only affects the speed test results.
Your site should not be able to run on HTTP (just thought I would say that for clarity) and should always redirect to HTTPS, hence why this is important.
Related
When I test my mobile website with my full URL: https://www.managerup.com I got a very good result on the PageSpeed-Insights.
When I enter however only managerup.com, Page Speed Insights redirects it to http://managerup.com and the score drops significantly on the mobile score.
Why is that?
By the way, in any browser, the redirecting from managerup.com to https://www.managerup.com works perfectly.
Why doesn't it work in Page Speed Insights?
Generally speaking, www.site.com is different from site.com, and any redirect 301 / CNAME setting should influence it in negative, for an obvious reason: you need one more step than standard one. Usually any domain has a domain canonical version, and you can find it here.
Usually PSI test exactly URL you give it, and score may be influenced by it - i.e example.it is generally different from www.example.it. If you configure at its best domain "variants", every single step may be taken into account for PSI.
You need also that rel=canonical attribute is right respect on it.
301 redirect would take worst (not better) PSI score than direct URL.
You should optimize website using a single, by default, single version.
I am Tani.
We are currently having an issue with a web service for a client wherein certain accesses to our page are resulting in an infinite redirect loop. We have been unable to reproduce the error, but because the issue is apparently solved by clearing the cache, it seems to be the case that cache data from a previous version of the site (different server, same domain) is resulting in unwanted redirects for some reason we are not quite certain of (again, nobody at our company can reproduce the behavior).
While investigating this, we discovered something odd. We are currently building a webpage with a series of unsecured landing pages that all transition to a single SSL-secured form. However, accessing the form via HTTPS (.htaccess always rewrites the request to use HTTPS when moving into a form action) will cause all future requests to the server to be interpreted as HTTPS, even those that are normally unsecured, until the cache is deleted.
By looking at the server's access log, we can see that this the request is being changed to HTTPS before it even hits our .htaccess. However, because the request is coming to the server with the S appended, we have no way of knowing what is causing the switch to SSL. It can be consistently reproduced by opening the secured form in one tab and then refreshing the other. We have tried restarting the servers, clearing the caches (application, firewall, etc.), but nothing seems to effect it.
The question itself is two-fold: first, is it a reasonable conclusion that this SSL-rewriting may, when combined with an old cache, result in an infinite redirect loop? And second , does anybody have any ideas which might cause HTTP requests to be rewritten as HTTPS?
Thank you for your time.
I have a site which is completely on https: and works well, but, some of the images served are from other sources e.g. ebay, or Amazon.
This causes the browser to prompt a message: "this website does not supply identity information"
How can I avoid this? The images must be served from elsewhere sometimes.
"This website does not supply identity information." is not only about the encryption of the link to the website itself but also the identification of the operators/owners of the website - just like it actually says. For that warning (it's not really an error) to stop, I believe you have to apply for the Extended Validation Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificate. EVC rigorously validates the entity behind the website not just the website itself.
Firefox shows the message
"This website does not supply identity information."
while hovering or clicking the favicon (Site Identity Button) when
you requested a page over HTTP
you requested a page over HTTPS, but the page contains mixed passive content
HTTP
HTTP connections generally don't supply any reliable identity information to the browser. That's normal. HTTP was designed to simply transmit data, not to secure the data it transmits.
On server side you could only avoid that message, if the server would start using a SSL certificate and the code of the page would be changed to exclusively use HTTPS requests.
To avoid the message on client side you could enter about:config in the address bar, confirm you'll be careful and set browser.chrome.toolbar_tips = false.
HTTPS, mixed passive content
When you request a page over HTTPS from a site which is using a SSL certificate, the site does supply identity information to the browser and normally the message wouldn't appear.
But if the requested page embeds at least one <img>, <video>, <audio> or <object> element which includes content over HTTP (which won't supply identity information), than you'll get a so-called mixed passive content * situation.
Firefox won't block mixed passive content by default, but only show said message to warn the user.
To avoid this on server side, you'd first need to identify which requests are producing mixed content.
With Firefox on Windows you can use Ctrl+Shift+K (Control-Option-K on Mac) to open the web console, deactivate the css, js and security filters, and press F5 to reload the page, to show all the requests of the page.
Then fix your code for each line which is showing "mixed content", i.e. change the appropriate parts of your code to use https:// or, depending on your case, protocol-relative URLs.
If the external site an element is requested from doesn't use a SSL certificate, the only chance to avoid the message would be to copy the external content over to your site so your code can refer to it locally via HTTPS.
* Firefox also knows mixed active content, which is blocked by default, but that's another story.
Jürgen Thelen's answer is absolutely correct. If the images (quite often the case) displayed on the page are served over "http" the result will be exactly as described no matter what kind of cert you have, EV or not. This is very common on e-commerce sites due to the way they're constructed. I've encountered this before on my own site AND CORRECTED IT by simply making sure that no images have an "http" address - and this was on a site that did not have an EV cert. Use the ctrl +shift +K process that Jürgen describes and it will point you to the offending objects. If the path to an object is hard coded and the image resides on your server (not called from somewhere else) simply remove the "http://servername.com" and change it to a relative path instead. Correct that and the problem will go away. Note that the problem may be in one of the configuration files as well, such as one of the config.php files.
The real issue is that Firefox's error message is misleading and has nothing to do with whether the SSL is an EV cert or not. It really means there is mixed content on the page but doesn't say that. A couple of weeks ago I had a site with the same problem and Firefox displayed the no-identity message. Chrome, however, (which I normally don't use) displayed an exclamation mark instead of a lock. I clicked on it and it said the cert was valid (with a green dot), it was a secure connection (another green dot), AND had "Mixed Content. The site includes HTTP resources" which was entirely accurate and the source of the problem (with a red dot). Once the offending paths were changed to relative paths, the error messages in both Firefox and Chrome disappeared.
For me, it was a problem of mixed content. I forced everything to make HTTPS requests on the page and it fixed the problem.
For people who come here from Google search, you can use Cloudflare's (free) page rules to accomplish this without touching your source code. Use the "Always use HTTPS" setting for your domain.
You can also transfrom http links to https links using url shortener www.tr.im. That is the only URL-shortener I found that provides shorter links through https.
You just have to change it manually from http://tr.im/xxxxxx to https://tr.im/xxxxxx.
I want to implement https on only a selection of my web-pages. I have purchased my SSL certificates etc and got them working. Despite this, due to speed demands i cannot afford to place them on every single page.
Instead i want my server to serve up http or https depending on the page being viewed. An example where this has been done is ‘99designs’
The problem in slightly more detail:
When my visitors first visit my site they only have access to non-sensitive information and therefore i want them to be presented with simple http.
Then once they login they are granted access to more sensitive information, e.g. profile information for which HTTPS is used to deliver.
Despite being logged in, if the user goes back to a non-sensitive page such as the homepage then i want it delivered using HTTP.
One common solution seems to be using the .htaccess file. The problem is that my site is relatively large meaning that to use this would require me to write a rule for every page (several hundred) to determine whether it should be server up using http or https.
And then there is the problem of defining user generated content pages.
Please help,
Many thanks,
David
You've not mentioned anything about the architecture you are using. Assuming that the SSL termination is on the webserver, then you should set up separate virtual hosts with completely seperate and non-overlapping document trees, and for preference, use a path schema which does not overlap (to avoid little accidents).
I have an interesting issue with HTTPS ports not being handled properly. It is a relatively small issue and I bet it is pretty simple to solve, I am just not thinking of it.
We have a website served with IIS 6, www.mylongdomainname.com. We have a secure portal which is handled via https://www.mylongdomainname.com. Now we have several vanity and marketing URLs that we use over the phone like www.shortname.com, etc. I have two websites setup, one that handles all request with the header www.mylongdomain.com which actually serves the website. The other accepts any traffic and permanently redirects to www.mylongdomain.com. This way if we ever add any more domains, they will all end up at the one, also it redirect mylongdomain.com to www.mylongdomain.com.
Everything here works fine. The issue now is when I google "shortname.com," the first result returned is the same as if I were googling "mylongdomain" however, google has been able to crawl the other pages via https://shortname.com and index them that way. We dont have SSL certificates for these other domains, so when you click through, you get a nasty un-trusted error.
This really wouldn't be an issue if we didn't use these URLs over the phone, and you all know how many people don't know the difference between the URL bar and a search box.
any suggestions or tips?
I'd set up a redirect so that https://shortname.com is sent to http://shortname.com with a 301 (permanent) redirect. This will put an end to the nasty untrusted error immediately. Furthermore, this will also cause Google to slowly but surely update their index.
There are multiple ways to do this. If you're using IIS7 you can use the URL Rewrite Module and write a redirect rule to take care of it.
Or if you're not on IIS7 it may be perfectly acceptable to write some code to accomplish this. I wrote some ASP.NET I've used plenty of times to take care of this HTTP/HTTPS redirection. In your particular case you could simply take my code and call SetSSL(False) in the Application_BeginRequest function of your global.asax.