lot of redirections

[mblendinger]

using latest version of cpanel and engintron, I can't use it, when I enable engintron, websites start failing about redirections. some tip please ?

[mblendinger]

note: the problem is with websites using CloudFlare, try changing settings, like ssl settings,but I cant found a silver bullet

[locksmithunit]

is not the problem the problem is the micro cache... i have it too... check your site here: https://hstspreload.org/ if the redirection error still showed, remove the micro cache... i need help with that too... is not on all my website, so i believe is conflicting in the pool of the cache... with another plugin or something like that. he did upgrade to the micro cache and the static. 2 mounts ago and i still not figure this... try activate micro caching in the http_common and i got an error any time :(

[locksmithunit]

i fix it. is the proxy key in dynamic: https://github.com/engintron/engintron/issues/1233

go i put everything here... amazing result, good luck :)

[fevangelou]

Did you check the Engintron docs? https://engintron.com/docs/#/pages/Engintron-&-CloudFlare

[locksmithunit]

Are you are serious!?!!!?!? (fevangelou) Documentations?!!??!

Are you REALLY thinking someone regular will search in all of that to find this with this costume string you create? AND EVEN IN THE DOCUMENTATION. THE EXPLANATION IS NOT CLEAR!

Where to put the block? in each file? in the rewrite? in the https? how to put that? each line? this is not clear information excuse me.

I am not a genius and i did not develop Nginx, the code and the locations of this stuff is more then regular develop using "Engintron" this Docomentions the only people will understand them is you!! and the guys invent NGINX!!!!! NOT YOUR REGULAR "USER / COSTUMER"

And after all of that i will notice to you: Is much simple to use my solution with the proxy_host key, Nginx creates it in purpose!! and NGINX is designed to do it without the string you provide in your documentation... and i am not a genius and i figure this out.

And fewer codes and strings... Nginx design to do stuff like that, and i don't need to be a genius and search in the documentation of a 1000000 pages, are you kidding me?

By the way, i am not speaking you ignoring me over 2 weeks for professional support from engintron ( not free of course ).

You are an AMAZING developer i sure about that. But you need to start to do something with your customer support... Engintron is really the next thing in the server world. you should think about that. ( is a compliment of course)

Regards, Nadav Levi Yahel Locksmith Unit

[locksmithunit]

BY THE WAY... I TRIED UNCOMMENT CLOUD FLARE ONLY BECAUSE YOU SAID TO DO IT... I REMOVE THE PROXY_HOST AND THE ERROR GOT AGAIN,

ERROR GOT SOLVE ONLY ON PROXY_HOST AND THIS THE BEST WAY THE MAKE THE KEY FOR THE HOST WITH NGINX REVERSE PROXY, THIS WHAT NGINX.COM RECOMENDED IN THERE SITE.

(THEY PROMISE ALL THE NGINX ORIGINAL KEYS WILL WORK NO MATTER WHAT, IF IS REVERSE PROXY OF COURSE) AND NGINX.COM RIGHT... ( SO FUNNY THIS GUY MADE NGINX HAHA )

YOU NEED UPDATE YOUR CODE BUDDY.... I LIKE IT... YOU HAVE DYNAMIC PUSH FROM THE PROXY HOST (HTTP) AND STATIC PUSH FROM $HOST WHAT PROGREMD THAT TO HTTPS... SO IS PUSH EVERYTHING IS NICE IDEA FOR YOUR SOFTWARE...

YOUR CNF FOR CPANEL AS WELL... YOU ARE THE BEST DEVELOPER I EVER SEEN BUT YOU NEED TO DO HOMEWORK MY FRIEND...

YOU ARE UNDERESTIMATE YOURS USERS... I MAYBE A "LOCKSMITH" BUT LIKE YOU KNOW LOCKSMITH TODAY IS HIGHTECH... I PROGREMED MERCEDES AND BMW COMPUTERS MORE EXPENSIVE FROM 10000 SERVERS WITH ENGINTRON.. IN ONE CAR. DESTROY ALGHORITHEM OR COMPUTER LIKE THAT IS NOT SOMETHIN CAN BE FIX... I COME FROM THE COMPUTER WORLD AND I VERY GOOD WITH HIGHTECH NO METTER IF IS BE NGINX, OR IS BE A COMPUTER ON A CAR.

I DIDNT KNOW NGINX. AND BECAUSE YOU REFUSE TO HELP YOUR CUSTOMERS EVEN WITH PAYMENT, I WAS NEEDED INVESTIGATED THIS AND GO DEEPER TO NGINX... I CAN TELL YOU AFTER 8 MOUNTS I WORK ON YOUR SOFTWARE. AFTER YOU BLOCK ME FROM ANY PAYMENT SUPPORT AND I TALK WITH YOU ON FACEBOOK.

I CAN ASSURE YOU I AM RIGHT. ( ABOUT PROXY_HOST ) RECOMMENDED FOR YOU: https://www.nginx.com/blog/

IT IS VERY SAD... YOU INVENT SOMETHING SO BIG AND SO GOOD ( ONE OF THE MUST USEFUL SERVER SOFTWARES )... BUT NOT REALLY SUPPORTED.

YOU NOT REALIZE WHAT YOU MADE HERE... REALLY, THIS SOFTWARE IS THE NEXT THING. REALLY SAD. 100% POTENCIAL 0% SUPPORT

REGARDS! NADAV LEVI YAHEL LOCKSMITH UNIT

[mblendinger]

Did you check the Engintron docs? https://engintron.com/docs/#/pages/Engintron-&-CloudFlare

of course, but thank you.

[fevangelou]

Nginx does not perform any redirects.

If you use Flexible SSL on CloudFlare and have .htaccess redirects from HTTP to HTTPS what do you expect will happen?

[locksmithunit]

Ok... i think i got something. and i going open a topic as well... mblendinger if you set in one of your websites inside the htacsses, an expire to the HTML this what triggers the problem. now WordPress 5.5.1 go out and a lot of plugins change themselves... recommended from now and on the set, the text/html expire at 0. ( apache inside htacsses ).

but if you will do it you will off the engintron dynamic cache... the redirects errors are because the expires... combined with text/html expire... i can't use it as well because i get the same problem... many many redirects OR! i have plugins change the png to webp get 404 if i turn on dynamic cache with expire in my htacsses... ( the expire is text/Html). I THINK DYNAMIC CACHE NOT WORKING PROPERLY... IN MY CASE IS NOT WORKING AT ALL BECAUSE I SET UP IN MY HTACSSES expire "html/txt 0sec" then Dynamic cache not growing...

MORE THEN THAT IF I WANT to USE IT HAVE A WAY TO GET RIDE FROM THE REDIRECTION... "proxy_host" will fix it but still... the dynamic cache still not growing.

it is will fix the redirection error because you on the default proxy key come from HTTP server... but the cache will not gonna grow and this looks like, don't have any effect from the dynamic cache.

i don't like it too... i want to use Engintron Dynamic cache but i cant... more then that... dynamic cache can conflict with IOS iPhones devices... this how i start notice to the problem...

i hope the developer does an update to engintron... have a lot of cpanel whm and WordPress core updates now and everything conflicts with each other included engintron.

[locksmithunit]

by the way another recommendation i notice on my c-panel. i delete in mistake the subdomain of the main domain. if you going to use "proxy_host" check you have subdomain to your main domain. (a c-panel design that with addon domain but to the main domain cant be an addon domain, is look wired and usually people not understand delete the subdomain for the main domain)

c-panel allows us to continue and everything looks fine... but this not a good approach. is can cause the redirect issue as well...

:)

[faca5]

Hello.

We have similar problem with latest version of Engintron for cPanel/WHM - v1.13.0 on subdomain. On previous version works without problem. Before upgrade works normally.

Settings: CloudFlare OFF .htaccess redirect OFF

Problem is ONLY with MAIN domain without "index.php".

Example: https://example.com/ not working, redirecting https://example.com/index.php working https://example.com:8443/ working

Error: The page isn’t redirecting properly

Note: When we first visited "https://example.com/index.php" and then "https://example.com/", it start working MAIN domain.

Solved: We have "Purge cache & temp files" and now it start working...

[fevangelou]

Then you have some internal PHP redirect which is not properly checking the current request protocol and blindly redirects to HTTPS either way.

If it's a WordPress site, some plugin is most likely to blame.

[Serjudo]

Hello, I have the same problem or a very similar one.

I am testing Engintron on my test server, before moving it to production, but I have redirection problems that I have not been able to solve so far.

In my case, the testing domain does not have Cloudflare enabled. If I deactivate Engintron it works fine. If I restart the Nginx and Apache services, it starts working after a while but without touching anything it suddenly starts to fail.

When it's failing, if I directly access the root domain https://desarrollopapelstore.factoriadigitalpremium.es/ it doesn't work, if instead of the root domain, I access an internal page of the domain it works without problems, and access to the root domain starts working (I guess because of a cookie issue). If I close the window and try again, it fails again.

Any suggestions?

[locksmithunit]

Then you have some internal PHP redirect which is not properly checking the current request protocol and blindly redirects to HTTPS either way.

If it's a WordPress site, some plugin is most likely to blame.

you blame WordPress, Nginx create for WordPress! come on you kidding me? today to everybody have WordPress! to ATAT, VERIZON even amazon site in WordPress... what are you talking about?

you tried to push HTTP INTO dynamic cache, NGINX know to recognize and choose the best one... about the PHP you can set in nginx in the http_common under the dynamic conf:

location / { try_files $uri $uri/ @backend; }

location @backend {

Engintron Proxy Params

include proxy_params_common;
# === MICRO CACHING ===
# Comment the following line to disable 1 second micro-caching for dynamic HTML content
include proxy_params_dynamic;

# Headers Engintron Dynamic Proxy
proxy_set_header              X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header              X-Forwarded-Host $PROXY_FORWARDED_HOST;
proxy_set_header              X-Forwarded-Port $server_port;
proxy_set_header              X-Forwarded-Proto $scheme;
proxy_set_header              X-Forwarded-Server $host;
proxy_set_header              X-Real-IP $remote_addr;
proxy_set_header              Accept-Encoding ""; # Optimize encoding

# Mobile Header Engintron Dynamic Proxy
proxy_set_header              X-UA-Detect $MOBILE; # Mobile Header

}

and you can even only to put the first header with the X-UA header... (after you put $schema in your key) common! you create engintron! this the most amazing Nginx i see even more the NGINX + go change your documentation and update the configs for your client!

if you was answering me and supporting the issue is was behind us.

and don't blame WordPress... you needed to put $schema in your dynamic key for people use dynamic cache plugins or other things actually NGINX SUPPORT!

Now i will ask you what your recommendation because after all, i think you are an amazing developer, and you made this software.

NGINX WAS BUILD TO SUPPORT ANY PLATFORM! HE FLEXIBLE AND THIS WHY EVERYBODY LOVE NGINX INCLUDED GOOGLE. so common give us support here, professional one dont blame other platforms.

[fevangelou]

@Serjudo There is most likely some broken /index.php to / redirect in the site's .htaccess file.

[faca5]

Old version works without problem.

Look like first visit - is the problem. We have "cookie" checking.

It is problem only on /

[fevangelou]

@faca5 Can you show me your code? A URL would also help me test your sent HTTP headers...

[faca5]

Url: https://alert.studiofaca.com/

.htaccess has: RewriteCond %{HTTPS} off RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If you visit https://alert.studiofaca.com/ it will show The page isn’t redirecting properly

An error occurred during a connection to alert.studiofaca.com.

This problem can sometimes be caused by disabling or refusing to accept cookies.

If you visit https://alert.studiofaca.com/index.php and then https://alert.studiofaca.com/ it will show content.

On previous version have havent all these problem.

If we FLUSH cache then for ~24 hours will work https://alert.studiofaca.com/

It is very strange. Looks like first visit create wrong cache and then nginx retrive wrong cache. We have upgraded on latest version but we will downgrade if this error still persists.

Custom Code: <FilesMatch ".(php)$"> Header set Set-Cookie "wp-protection=1"

[fevangelou]

@faca5 The important difference between v1.12 and v1.13 is that Engintron's Nginx setup is now configured for better caching. If you send the right HTTP headers, Nginx will properly cache the content (server-side).

Test your site with: curl -I "https://alert.studiofaca.com/"

Notice that: a) you still get a 301 redirect, which means your .htaccess redirect is bad. Remove that .htaccess rule, purge Engintron's cache and check the URL using a private window. b) you have an extremely high cache-control header (cache-control: max-age=259200). Nginx respects that and serves a cached copy. Cookies are ignored when building its cache. c) Now try querying the domain using a random query string, something that an uptime tool would use for example. E.g. https://alert.studiofaca.com/?t=20201002 - You'll now get a 406 response (!). This indicates the app is not routing all requests properly.

Moreover, this app seems to be entirely for user-generated content. As such, you should 100% disable any caching for it, using Engintron's custom rules.

And to conclude, the issues are entirely app specific.

My guess is that similar issues occur for everyone else.

To all: Guys, please do some digging on your own too. Use curl to examine your affected site's headers. Triple-check your .htaccess rules (don't just use the first one that's returned on a Google result).

[fevangelou]

@faca5 Bonus point:

$ curl -I "https://alert.studiofaca.com/index.php"
HTTP/2 406 
server: nginx
date: Sat, 10 Oct 2020 09:10:25 GMT
content-type: text/html; charset=iso-8859-1
content-length: 373
x-xss-protection: 1; mode=block
x-content-type-options: nosniff

Routing is wrong in the app (returns a 406 HTTP code). Nginx only caches responses returned with a 200 code. Thus, no caching occurs. That's why you see the updated page.

Both issues you have (redirect & caching) are all because of bad .htaccess rules and bad app routing.

[Serjudo]

Thank you for the answers,

I can confirm that my problems seem to have been solved, eliminating all the redirections that I had configured in the .htaccess file. Both those that transformed the requests to https, and those that removed or added www before the url.

I have also activated it in production (domain with cloudfare enabled) and after removing the redirects it also seems to work perfectly.

@fevangelou Maybe you should add an entry in the documentation, talking about this, because it seems that at least in my case, this kind of redirects are not compatible with Engintron.

Thanks for your help.

[fevangelou]

@Serjudo It's not "just" redirects. It's bad redirects :) Apache .htaccess rules that may work in Apache (which is more forgiving compared to Nginx) does not mean they'll work in Nginx too when exposed to it in a proxy scenario.

[fevangelou]

Besides, I can't possibly document that "hey, if you got X & Y bad .htaccess rules, things will break". This should be common sense.

[faca5]

Hello.

We will check. Thank you.

[Serjudo]

@fevangelou I agree that these are possibly bad redirections, I am certainly not an expert on this subject.

If it helps, these are the redirections that previously worked with Apache, and after the installation of Engintron, they don't work properly:

For the https redirection, I used this first: RewriteCond %{HTTPS} off RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

and then I tried this: RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

this for the redirection, adding www at the beginning: RewriteCond %{HTTP_HOST} ^xxxxxxxxxx.es RewriteCond %{HTTP_HOST} !^xxxxxx.xxxxxxxxxx.es RewriteRule ^(.*)$ https://www.xxxxxxxxxx.es/$1 [R=301,L]

[Serjudo]

Hello again,

I'm afraid I have problems again from time to time with redirection, which only affect access to the root domain of the page and are solved by clearing the cache in nginx.

It was working perfectly for more than 3 days and without touching anything in the configuration, such problems recur from time to time.

In production I have Cloudfare activated but only for DNS redirection. The SSL/TLS encryption mode is Full (I have a self-signed SSL certificate installed on the server) and I added in the custom rules of Nginx set $PROXY_DOMAIN_OR_IP "xxx.xxx.xx.xx" as indicated in the docs.

On Cloudfare I also have the following options enabled: Always use HTTPS Automatic HTTPS rewrites

As for the .htaccess file, I deactivated the redirections I thought were presenting the problem. These are the ones that I still have active, that working in Apache work perfectly:

RewriteCond %{REQUEST_URI} "/testimonial/" RewriteRule (.) $1 [L] RewriteCond %{REQUEST_URI} "/downloader/" RewriteRule (.) $1 [L] RewriteCond %{REQUEST_URI} "/rss/" RewriteRule (.*) $1 [L]

rewrite API2 calls to api.php (by now it is REST only)

RewriteCond %{REQUEST_URI} !^/[0-9]+..+.cpaneldcv$ RewriteCond %{REQUEST_URI} !^/.well-known/pki-validation/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ RewriteRule ^api/rest api.php?type=rest [QSA,L]

TRACE and TRACK HTTP methods disabled to prevent XSS attacks

RewriteCond %{REQUEST_METHOD} ^TRAC[EK] RewriteCond %{REQUEST_URI} !^/[0-9]+..+.cpaneldcv$ RewriteCond %{REQUEST_URI} !^/.well-known/pki-validation/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ RewriteRule .* - [L,R=405]

RewriteCond %{REQUEST_URI} !(downloader) [NC] RewriteCond %{THE_REQUEST} ^./index.php RewriteRule ^(.)index.php$ https://www.papelstore.es/$1 [R=301,L]

always send 404 on missing files in these folders

RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

exception for mod_pagespeed URLs

RewriteCond %{REQUEST_URI} ! pagespeed

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-l

rewrite everything else to index.php

RewriteRule .* index.php [L]

BLOCK git & svn and redirect to homepage access to dir var

RewriteRule ..git/. - [F] RewriteRule [F] RewriteRule ^var/(.*)$ www.papelstore.es [R=301,NC,L]

Can you help me?

[jackwakefield]

Adding $scheme back to proxy_cache_key solved this for us.

[fevangelou]

@jackwakefield Adding $scheme to https://github.com/engintron/engintron/blob/master/nginx/proxy_params_dynamic#L78 will simply create 2 cached copies of the same content. Not really efficient, unless you serve different content indeed.

@Serjudo I've demonstrated already and in detail that bad redirections and/or bad HTTP headers coming from a site/app are the cause of such issues. I can't possibly do this forever. Engintron is a free plugin. Do some (thorough) digging on your own.

[faca5]

Adding $scheme back to proxy_cache_key solved this for us.

Hello.

It works.

We have set redirect from HTTP to HTTPS. This is the main problem. It cache HTTP redirect instead HTTPS.

Thank you very much.

[fevangelou]

I'm curious to see that redirect of yours @faca5 which causes such a weird issue...

[fedealvz]

Thank you @fevangelou

When .htaccess have two redirects (1st for "http to https" and 2nd for "non www" to "www") it will redirect the first rule, but the second it will cause "too_many_redirects".

# 1st rule "http to https"
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# 2nd rule "non www to www"
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Response:

http://domain.com
    301 Moved Permanently
https://domain.com/
    301 Moved Permanently
https://domain.com/
    301 Moved Permanently
https://domain.com/
    301 Moved Permanently
...etc...

[locksmithunit]

OK GUYS, i find a solution for you and a good one. but you do not see HTTP status because you redirect him immediately with "if" like in the costume rules OF ENGINTRON FOR CLOUDFLARE.

## Redirects Dynamic ##
if ($scheme != "https") {
    return 301 https://$host$request_uri;
    return 301 https://www.$host$request_uri;
}

you can put it in the costume rule config in the END OF HIM!

remove the $schema from dynamic params. (you even can bring back the expires mod for apache but i am not recommended...)

enjoy everybody 👍

@fevangelou to me it takes 3 weeks to find this stoped rule... something you were able to provide in a minute... wish you luck

[locksmithunit]

OK, FINAL FIX! IS THE SAME CODE BUT REDIRECT TO ENGINTRON Redirect SSL @fevangelou you really shame yourself... your knowledge on your own software is a shame, really god give nuts to people without teeth. this what's going on with you.

everybody this the final solution and i promise it will solve any redirect. first, remove the $schema from my first suggestion. ( from engintron Dynamic_Paramas inside the key )

after that.

go to costume rule and go to the first part when you will find:

# === FOR USE WITH CLOUDFLARE ===
#
# a) If your server has a single shared IP ONLY and you wish to use CloudFlare for any (or all) of your sites
#    you will have to specify this shared IP address below otherwise you'll get errors from CloudFlare.
#    This change will simply tell Nginx to skip DNS resolving and just forward traffic to the shared IP.
#    Uncomment the following line if all your sites on the shared (main) IP of your server are on CloudFlare:
#
set $PROXY_DOMAIN_OR_IP "XX.XXX.XXX.XXX"; # Use your cPanel's shared IP address here

PUT YOUR IP INSIDE.

THEN GO LITTLEL BIT LOWER UNTIL YOU WILL SEE: set $redirToSSL ""; `

REPLACE IT WITH THAT:

set $redirToSSL "";

## Redirects Dynamic ##
if ($scheme != "https") {
    set $redirToSSL "on";
}

## CloudFlare Redirect ##
if ($http_cf_visitor ~ '{"scheme":"http"}') {
    set $redirToSSL "on";
}
#
# # Set each domain you DO NOT want to automatically redirect to HTTPS when using CloudFlare only below
# # and repeat the process with additional "if" blocks for more domains
#

#if ($host ~ 'yourdomain.com') {
#    set $redirToSSL "off";
#}

if ($redirToSSL = "on") {
    return 301 https://$host$request_uri;
}

I Promise this the best i have, and the best anyone will find included @fevangelou, ohhh this guy...

ENJOY EVERYBODY AND PLEASE UPDATE HERE ON RESULTS :)

[locksmithunit]

Thank you @fevangelou

When .htaccess have two redirects (1st for "http to https" and 2nd for "non www" to "www") it will redirect the first rule, but the second it will cause "too_many_redirects".

# 1st rule "http to https"
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# 2nd rule "non www to www"
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Response:

http://domain.com
  301 Moved Permanently
https://domain.com/
  301 Moved Permanently
https://domain.com/
  301 Moved Permanently
https://domain.com/
  301 Moved Permanently
...etc...

Hey about your issue. you put the string twice... this the right code for your htacssas via c-panel:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTP_HOST} ^website\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.website\.com$
RewriteRule ^(.*)$ "https\:\/\/website\.com\/$1" [R=301,L]
</IFModule>

NOW IF YOU WANT SOMETHING BETTER IS: (BUT I DONT GUARANTY IS WILL WORK PERFECT ON YOU SYSTEM.)

###############################################################################
### cPanel Certificate | Comodo DCV + HTTPS
###############################################################################
# Let apache know we're behind a SSL reverse proxy
SetEnvIf X-Forwarded-Proto "https" HTTPS=on

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !on
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$ 
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteCond %{HTTP:X-Forwarded-Proto} !https [NC]
RewriteCond %{HTTP_HOST} ^locksmithunit\.es$ [OR]
RewriteCond %{HTTP_HOST} ^www\.locksmithunit\.es$
RewriteRule ^(.*)$ "https\:\/\/locksmithunit\.es\/$1" [R=301,L]
</IFModule>

THIS WILL STOP THE LOOP INSIDE YOUR WEBSITE, BUT! IS WILL NOT STOP THE MANY MANY REDIRECTION FROM HTTP 301... FOR THIS LOOK ON MY MESSAGE BEFORE THIS ONE AND FIX NGINX REDIRECTION AS I PROVIDE ONE MESSAGE BEFORE THIS ONE...!

AFTER ALL OF THAT, I ASSURE YOU EVERYTHING BE FINE :)

[fevangelou]

I think cPanel's redirect is better. See this:

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

In any case, I've just released v1.14.0 which re-instates the $scheme in proxy_cache_key. This should resolve your redirect issues.

[locksmithunit]

I think cPanel's redirect is better. See this:

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

In any case, I've just released v1.14.0 which re-instates the $scheme in proxy_cache_key. This should resolve your redirect issues.

@fevangelou THANK YOU! i happy you decided to fix it once for all. btw when i did the redirection from c-panel i got {HTTPS} off AND RewriteCond %{HTTP:X-Forwarded-Proto} !https

with URL and Slashes for proxy, with my domain on it. with a wild card. i will install now the update and update you.

Thank you again for your help. I am very happy you decided to do the update.

I still didn't see it on the panel... if i update engintron is will update the version? usually have green pop up notification tell you to have a new version, but i don't have it.