Hasn't been a totally clean switch either. I expected some odd behaviour here and there, but I've noticed quite a bit, even from browsers with common user agents that should support HTTPS 100%.
Here's some log entries. The last value is the port (HTTP=80, HTTPS=443).
There's browsers which switch without fuss, going from port 80 to 443 within a second:
Code:
x.x.x.x - - [26/Feb/2017:04:19:33 +1100] "GET / HTTP/1.1" 302 - https://www.google.com/ 55308 0 80
x.x.x.x - - [26/Feb/2017:04:19:34 +1100] "GET / HTTP/1.1" 200 1878 https://www.google.com/ 55308 0 443
(...fetch all future objects on port 443)
There's browsers which are delayed for some reason, perhaps because of a user confirmation dialog? This IP had 22 seconds between the redirect (HTTP) and the content fetch (HTTPS) :
Code:
x.x.x.x - - [26/Feb/2017:04:19:47 +1100] "GET / HTTP/1.1" 302 - - 55278 0 80
x.x.x.x - - [26/Feb/2017:04:20:09 +1100] "GET / HTTP/1.1" 200 1878 - 55308 0 443
Then there's these browsers, which don't redirect to HTTPS, and they continue connecting to port 80, even though the referer suggests they're HTTPS capable:
Code:
x.x.x.x - - [26/Feb/2017:04:22:13 +1100] "GET / HTTP/1.1" 302 - https://www.google.com/ 55278 0 80
x.x.x.x - - [26/Feb/2017:04:22:31 +1100] "GET / HTTP/1.1" 302 - https://www.google.com/ 55278 0 80
x.x.x.x - - [26/Feb/2017:05:22:43 +1100] "GET / HTTP/1.1" 302 - http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=[.....] 55278 0 80
Note he gave up for an hour, then tried again...
It's the latter case that concerns me, because it looks like they're no longer able to access the site at all. I ended up writing some extra scripting that only sends the 302 HTTP->HTTPS redirect once; if the browser continues to connect to port 80, it will fall back to permitting normal site access via HTTP.
So far around 19% of IPs have hit that fallback exception, which seems a very high number.
