strange URI problem

I think this is a ISPConfig related issue. I've moved over to https but the redirects are acting funny, either with my own manual one or the built in http to https checkbox.

What was happening is that when URI's for directories have a trailing slash it works fine, but if there's no trailing slash it shows the apache default 404 instead of resolving the URI.

Basically:
http://cutcodedown.com/for_others/ -- worked
http://cutcodedown.com/for_others -- didn't work. Behaves as if you called it via the IP address.

If also worked when www was included.

Oh, and for some reason it works in chrome either way. But FF, Edge, IE, and Safari all don't work. JUST to make diagnosing this one even harder.

For now I've "fixed" this by adding my usual redirect:

Code:

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,NE,R=301]

to the 000-default.conf... but that's treating a bullet wound with a band-aid. I'd like to know why if there's no trailing slash on a directory it's behaving as if the hostname isn't recognized. WORSE, I'd like to know why when it was doing a 404 it wasn't logging in in /var/log/apache2...

My redirect (which includes www to non www) or the in-built one (which BTW seems flaky as hell) makes no never mind. WORSE even if both redirects aren't present, it still sends the non-slash URI to the default /var/www/html directory's content/handling. I tested this by adding custom /errors and the ErrorDocument commands to 000-default.conf as well. As such it's not the redirects that are messing up, but as if it's not even listening on port 80 when https is enabled.

Is that what's going on? No, cause if that was the case inclusion of the trailing slash or www wouldn't "fix it".

Very strange corner-case issue. It's clearly not the redirects since it still does it with them removed... I feel like it's probably something minor and stupid I'm just not seeing or thinking of.

 

Yeah, the workaround is up... sadly it fixes ALL domains on the server so it's hard to test without dropping it.

I used one of my domains as a test with no .htaccess or even proper redirects, and still if it's http without www and a trailing slash, it returns the default 404. Not even the domain one. It's literally like it's flat out ignoring the domain name at the virtual hosts level meaning to my mind, Apache isn't even getting that far.

apachectl spits out this:

Code:

AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.conf:73
VirtualHost configuration:
*:8081                 cutcodedown.com (/etc/apache2/sites-enabled/000-apps.vhost:9)
*:8080                 cutcodedown.com (/etc/apache2/sites-enabled/000-ispconfig.vhost:9)
*:443                  is a NameVirtualHost
         default server deathshadow.com (/etc/apache2/sites-enabled/100-deathshadow.com.vhost:114)
         port 443 namevhost deathshadow.com (/etc/apache2/sites-enabled/100-deathshadow.com.vhost:114)
                 alias www.deathshadow.com
         port 443 namevhost forums.cutcodedown.com (/etc/apache2/sites-enabled/100-forums.cutcodedown.com.vhost:113)
         port 443 namevhost x86.cutcodedown.com (/etc/apache2/sites-enabled/100-x86.cutcodedown.com.vhost:93)
         port 443 namevhost cutcodedown.com (/etc/apache2/sites-enabled/900-cutcodedown.com.vhost:114)
                 wild alias *.cutcodedown.com
         port 443 namevhost elementalsjs.com (/etc/apache2/sites-enabled/900-elementalsjs.com.vhost:114)
                 wild alias *.elementalsjs.com
         port 443 namevhost ewiusb.com (/etc/apache2/sites-enabled/900-ewiusb.com.vhost:114)
                 wild alias *.ewiusb.com
*:80                   is a NameVirtualHost
         default server cutcodedown.com (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost cutcodedown.com (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost deathshadow.com (/etc/apache2/sites-enabled/100-deathshadow.com.vhost:7)
                 alias www.deathshadow.com
         port 80 namevhost forums.cutcodedown.com (/etc/apache2/sites-enabled/100-forums.cutcodedown.com.vhost:7)
         port 80 namevhost x86.cutcodedown.com (/etc/apache2/sites-enabled/100-x86.cutcodedown.com.vhost:7)
         port 80 namevhost cutcodedown.com (/etc/apache2/sites-enabled/900-cutcodedown.com.vhost:7)
                 wild alias *.cutcodedown.com
         port 80 namevhost elementalsjs.com (/etc/apache2/sites-enabled/900-elementalsjs.com.vhost:7)
                 wild alias *.elementalsjs.com
         port 80 namevhost ewiusb.com (/etc/apache2/sites-enabled/900-ewiusb.com.vhost:7)
                 wild alias *.ewiusb.com
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex fcgid-pipe: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex fcgid-proctbl: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: ENABLE_USR_LIB_CGI_BIN
User: name="www-data" id=33
Group: name="www-data" id=33

My fix works for now, but it's a very strange behavior to come across. Made all the stranger by the fact that blink based browsers -- chrome, vivaldi, opera -- have no problems, but all other browsers -- IE, Edge, FF, Safari -- exhibited this bizzare behavior. A behavior that was even worse on iOS since there was also some strange massive long delay. It was like a redirect loop was in place, but it was doing it even when redirects were disabled.

Turning off HTTPS for the test domain also fixed the behavior.