5 days ago I've attached my website on Cloudflare to serve website js and CSS file from here. but didn't show right now. The Cloudflare showing domain is active.
Please tell me what I did wrong.
It's easy to check the URI is served by Cloudflare or not.
Check the HTTP(S) response header to see if server is identified as Cloudflare and the existence of _cfduid cookies in the response header.
curl -svo /dev/null https://www.findtoptenranks.com 2>&1 | grep "server:"
< server: cloudflare
You can use online benchmarking tools like WebPageTest to measure the performance of your website. I can see that your site have almost 68% of static assets cached by Cloudflare, try to consider moving the external resources to your server so that Cloudflare can cache them as well.
Page Weight # Size %
-------------- -- --------- -------
Cache HIT 62 707.50KB 67.91%
NOT Caching 3 22.56KB 2.17%
External 19 311.72KB 29.92%
Total 84 1041.78KB 100.00%
Related
I've uploaded my static files to S3. To cache my files into CDN (and reduce aws cost + better SEO results), I'm using cloudflare.
My bucket name is cdn.mydomainname.com
My Cloudflare CNAME configuration is cdn (name) and cdn.mydomainname.com.region_code.s3.amazonaws.com(alias)
However, there's a problem. Whenever, I browse my webpages, the static files does not load because of https error stating Your connection is not private. Upon accepting it, my image url cdn.mydomainname.com/image.jpeg is redirected to https://region_code.amazonaws.com/cdn-mydomainname-com/image.jpeg. Now when I check my network logs, the image is not cache by Cloudflare, as I can see below in my response headers.
Server: AmazonS3
x-amz-id-2: some_id
x-amz-request-id: some_id
I've read through multiple blogs, SO questions and documentation, but I'm not able to find the solution.
Some people recommend not to use bucket name as cdn.mydomainname.com. Instead use something like cdn-mydomainname-com.
Now my Cloudflare CNAME configuration is cdn (name) and cdn-mydomainname-com.region_code.s3.amazonaws.com(alias)
There are 2 problems with it.
1) My urls will not be pretty (https://region_code.amazonaws.com/cdn-mydomainname-com/image.jpeg). This will negatively impact my SEO.
2) It again shows the same response headers as shown previously.
Server: AmazonS3
x-amz-id-2: some_id
x-amz-request-id: some_id
What can be done to curbe this? Where am I wrong
UPDATE
I tried to host a static file on my server, and that file is served from Cloudflare as checked in the response headers (CF-CACHE-STATUS: HIT)
Try pointing CloudFlare's CNAME to
cdn-mydomainname-com.region_code.s3.amazonaws.com
but leave your bucket name as
cdn.mydomainname.com
and access your image at
cdn.mydomainname.com/myimage
S3 will use the hostname that CloudFlare sends when looking up the bucket not the subdomain. Indeed you can put any subdomain in CloudFlare you want. The important part is that the subdomain has no dots in it. The certificate S3 presents to CloudFlare is a wildcard certificate of form
*.region_code.s3.amazonasw.com
so CloudFlare will accept it as valid for
cdn-mydomainname-com.region_code.s3.amazonaws.com
and the image will pass through CloudFlare as desired.
I have disabled SSL in all pages at Prestashop and now there is this error (i do not enter https and it puts https):
I tried deleting htaccess and regenerating it, but it didn't work.
This is the Prestashop configuration:
Which is the solution?
EDIT: My configuration of SSL at Prestashop configuration tab
I'm not familiar with Prestashop, however the issue is that at the time being the site enforces the HTTPS. In fact, the non-HTTPS version redirects to the HTTPS, there may be other redirects (that are not enabled now as I can access the redirect target) that may have caused the loop.
➜ ~ curl -I http://runvaspain.com
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sun, 24 Jan 2016 10:44:09 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: no-cache
Location: https://runvaspain.com/
X-Powered-By: PleskLin
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15768000;includeSubDomains
Moreover, it looks like the site is setting the HSTS header
Strict-Transport-Security: max-age=15768000;includeSubDomains
This header is ignored when served via HTTP, however I suppose this was also served via HTTPS, therefore your browser have probably saved the configuration and it's enforcing the HTTPS locally (given that's what the HSTS is about).
You'll have to manually remove the strict transport configuration for the domain in your browser. However, please note that any user that previously accessed your site will have such setting, therefore they will be forced to use HTTPS for the main site and all subdomains for 6 months (as this is the policy you previous set).
Also note that, since you previously sent that header, HTTPS will be enabled for the entire site (and also subdomains), it's not possible to enable it on a single page (at least for the users who visited it before). The best thing to do is to turn HTTPS on again for the entire site.
To solve the first issue (the redirect to HTTPS) you should contact the Prestashop service. However, please note it will be almost irrelevant if the HSTS header was previously sent.
The http version of the website ( http://runvaspain.com ) send a 301 redirect to the https version.
The https version of the website ( https://runvaspain.com ) use the HSTS header with a max-age of 6 month
That's mean that anyone who visited the website is forced to visit the HTTPS version
It's a security feature added by HSTS.
You have two solutions:
Reactivate the https version (It's my advice, as https add a significant security to your visitors)
Redirect the https to http AND modify the HSTS header (probably in your apache configuration) to send a max-age of 0. You MUST send it for at least 6 month, you can't just remove it! Sending a max-age on 0 indicate to visitors who already visited the website to forget the HSTS settings. If you just remove it, those visitors will not be able to visits the webpage for the next six months !
in prestashop after configure with ssl, admin dashboard works. but public sites doesn't work anymore. because you have to enable SSL for front pages, using admin dashboard like bellow.
Enable SSL - yes
Enable SSL on all pages - yes
change your shop parameters like this
refer the image
I think Chrome just cached the URL. Happens to me all the time during development.
Try
List item
Click Menu (three dots or whatever icon is it now in Chrome in the upper right corner)
Hover over More tools then Developer tools
Click Network tab
Click Disable cache checkbox
I have a strange problem which I can't identify the cause of.
There are two servers which host two different sites. Both sites are PHP-based apps.
Server 1 (Ubuntu)
https://app.site1.com
Server has SSL enabled for this site. This site works fine.
Server 2 (Red Hat)
http://app.site2.com
Server does not have SSL enabled for this site.
Here's what happens:
If I access site 2 on http:// it works fine.
If I access site 2 on https:// it redirects to site 1 on the other server.
Now obviously there is something telling this subdomain to go to the other site when served via SSL.
What I have checked:
All virtual hosts on both servers
All DNS records on both servers
All Site 2 website code
Site 2 .htaccess files
Using uncached browsers
There is NOTHING on either of the servers, that I can find, telling site 2 to redirect to site 1, only on HTTPS. Now obviously I don't expect anybody to find the problem directly because you can't see my entire server configuration, but I am looking for suggestions as to where else this redirect could come from.
I could understand this if you had site1 and site2 hosted on the same server.
Basically if you have no config set up for a second vhost on https (port 443) then Apache will fall back to first vhost by default.
So if both sites were in same Apache config then that might be it. But you say they are not. Are you sure you are not serving both sites from the same server (perhaps with a copy in the other server)? Are the IP addresses the same? Are there any load balancers or CDN infrastructure in front of both servers?
Also you say "If I access site 2 on https:// it redirects to site 1 on the other server." Can you explain more about what happens here? If you go to site 2 and do not have https set up then how can this even respond to this request? What certificate is being presented to that initial request (i.e. before the redirect)? Is it the site1 certificate? And if so then do you get a certificate error in the browser (since its presenting the wrong certificate for the site you requested) that you have to click through before you get redirected? Or is the cert valid for both sites?
You can also use this openssl command to see what the server returns (and in particular which certificate it returns):
openssl s_client -connect app.site2.com:443
It would also be handy to look at the browsers developer tools and see how exactly the redirect is happening. In Chrome press F12, go to Network tab, click on preserve log and then go to https://app.site2.com/. What is the first request? Is it a 301 or 302 (i.e. Server side redirect)? Or if it's a 200 followed by the https://app.site1.com/ then some piece of JavaScript must have caused the redirect.
Once you have answered those questions it may be possible to provide further guidance.
I am having some trouble with some but not all my subdomains when using cloudflare.
The apache virtualhost redirects that don't involve ports are all ok...
eg:
http://domain.com.au/gallery > http://gallery.domain.com.au works ok and all run through cloudflare (orange cloud) as they should.
Noting the following:
1. BIND9 and apache had a working A record / virtualhost redirect prior to connecting via cloudflare
2. CloudFlare cloud for this DNS A record is grey not orange
Where I am having trouble is in the following examples:
http://domain.com.au:767/web > http://subdomain1.domain.com.au
http://domain.com.au:7979 > http://subdomain2.domain.com.au
The errors I am getting on this when trying connect through a browser are timeout errors. Help / ideas on how to fix this?
The best work around I have found involves:
Create a Page Rule with the following:
URL Pattern = http://subdomain2.domain.com.au
Turn on forwarding
Destination URL = http://0.0.0.0:7979 (change 0.0.0.0 to your IP Address)
Go back to CloudFlare DNS settings and turn on the orange clouds.
What this seems to do is route traffic through the CloudFlare system and then the Page Rule grabs it and directs it to the pure IP address. It displays a terrible looking URL however it works.
This is a rather complicated scenario, so I would highly appreciate any pointer to the correct direction.
So I have setup apache on server A to proxy https traffic το server B, that is a plone site behind varnish and apache.
I connect to A and can browse the site on https, everything is fine. However, problems start when I upload files, via plone's POST forms. I can upload small files (~1 MB), but when I try to upload a 50MB file, I wait all the time till the file is uploaded, and when the indication is 100%, I get a Bad gateway (The proxy server received an invalid response from an upstream server.)
It seems to me that something timeouts between the communication of A and B and instead of being redirected to the correct url, I get a Bad gateway, not to mention that the file is not uploaded.
On the apache log I see
[error] proxy: pass request body failed
As suggested on other threads, I've experimented with the following values with no luck
force-proxy-request-1.0
proxy-nokeepalive
KeepAlive
KeepAliveTimeout
proxy-initial-not-pooled
Timeout
ProxyTimeout
Sooooo..any suggestions? Thanks a million in advance!
Did you check the varnish configuration? varnish has some timeouts of its own, I am familiar with send_timeout which usually breaks downloads if they fail to finish within a few seconds (Varnish really isn't any good for large downloads, because you end doing stupid things like configuring send_timeout=7200 to make it work).
Also, set first_byte_timeout to a larger number for that backend, because a large file upload might delay plone's response just enough to cause this.
Setting the Timeout and KeepAliveTimeout in the apache virtual host file worked for me.
Example:
Timeout 3600
KeepAliveTimeout 50