Earlier quoted context omitted.
Just because the same IP address also listens on port 443 doesn't mean that delivers the same website, and assuming it does is not a failure on their part, it's a failure of assumptions you or some software you utilize (knowingly or not) has made along the way.
Indeed it doesn't. So why are they returning status code 200? > not a failure on their part, it's a failure of assumptions you or some software you utilize No, it is a failure on their part. They're returning the wrong status code. The software I utilize checks that, they got it wrong. Return 404 instead.
A webserver listening on a specific IP on port 80 and serving HTTP traffic, but using name based virtual hosting (reading the Host: header) to determine what site to deliver. We'll say it's configured for emample1.com and example2.com.
The same webserver (or a different one, it doesn't matter) listening on that same IP, but port 443, and serving HTTPS traffic. Without use of some newer SSL/TLS/HTTPS protocol features (which aren't universally supported), the certificate needs to be served before any regular HTTP traffic is sent across the encrypted tunnel. Which cert do you serve?
You can argue that it's probably good practice to not have named based virtual sites on the same IP as SSL sites, or that if you access the SSL site with the wrong hostname it should respond in error, and I think you would be correct.
But agreeing on best practices doesn't mean the site is set up wrong, just that it could be set up in a more robust way. It my be set up in a perfectly valid configuration.
It's wrong to assume when you can access a site on port 80 that if that same IP address responds to port 443 that it should serve the same site.
> The software I utilize checks that, they got it wrong. Return 404 instead.
The software you use should be checking that the cert served matches the site requested, and not try to upgrade the connection to HTTPS if it doesn't.