Lukas Tribus Wrote:
---
> As I said, the best way would be to drop the TLS handshake, but nginx
> doesn't support this afaik.
If you mind the overhead, ssl_preread_server_name could be used for this.
Posted at Nginx Forum:
https://forum.nginx.o
> Why should I? I clearly defined the problem/misconfiguration. I don't
> really see the need to justify why I want to fix it.
To help others, myself included to comprehend a possible problem in similar
configurations and learn more about it. After all, this is a community.
> Well, you told me
On 11/30/2016 09:17 AM, Lukas Tribus wrote:
Does it cause warnings in the webmaster tools? Who cares?
Does it affect your ranking? I doubt it.
Does it index pages or error pages from the default website and assign to
your website? I doubt that even more.
Does it upset my customer? YES.
That's
> > Does it cause warnings in the webmaster tools? Who cares?
> > Does it affect your ranking? I doubt it.
> > Does it index pages or error pages from the default website and assign to
> > your website? I doubt that even more.
>
> Does it upset my customer? YES.
>
> That's all the justification I
On 11/29/2016 09:28 PM, Lukas Tribus wrote:
What I don't see is why and how that would be a problem, even when HTTPS
is not properly setup for that particular domain.
Does it cause warnings in the webmaster tools? Who cares?
Does it affect your ranking? I doubt it.
Does it index pages or error
There's no "nice" way to handle this in nginx as far as I'm aware. I think
the best setup is a default vhost with a generic (server hostname?)
certificate, and for any bots or clients that ignore the common name
mismatch you can return the 421 Misdirected Request code.
https://httpstatuses.com/421
> > Any real life experience and evidence backing this?
> yes
Care to elaborate?
> Not sure why you're doubting me here Lukas. Yes, this is a problem. No
> I'm not making it up.
We know that crawlers like Googlebot try HTTPS as well, even if there is no
https link towards the website. That is
On 11/29/2016 09:55 AM, Lukas Tribus wrote:
It seems that search engines are probing https: even for sites that
don't offer it
Which is fine.
just because it's available for others, with the end
result that pages are being attributed to the wrong site.
Sounds like an assumption. Any rea
> It seems that search engines are probing https: even for sites that
> don't offer it
Which is fine.
> just because it's available for others, with the end
> result that pages are being attributed to the wrong site.
Sounds like an assumption. Any real life experience and
evidence backing t
