3 ms·

I think what I had seen before was replacing the http variant of the "bad request" page with a redirect to the HTTPS base URL something akin to https://serverfa

I think what I had seen before was replacing the http variant of the "bad request" page with a redirect to the HTTPS base URL something akin to https://serverfault.com/a/1063031 https://serverfault.com/a/1063031. Looking at it now this is probably more "hacky" than it'd be worth and, as you note, probably comes with some security risks (though for a local development app like this maybe that's acceptable just as using plain HTTP otherwise is), so it does sense that's not an included feature after all.

bangaladore 2y ago
I don't think that really applies here. In general the way that works is user navigates to http://contoso.com http://contoso.com which implicitly uses port 80. Contoso server/cdn listening on port 80 redirects them through whatever means to https://contoso.com https://contoso.com which implicitly uses 443. I don't see value on both being on the same port. Why would I ever want to support this when the http: or https: essentially defines the default port. Now ofcourse someone could go to http://contoso.com:443 http://contoso.com:443, but WHY would they do this. Again, failing to see a reason for this.
- zamadatix 2y ago
  I (and the provided link) are not referring to http://example.com:80 http://example.com:80 to https://example.com:443 https://example.com:443 type redirects, though those are certainly nice too. They are, indeed, solely about http://example.com:443 http://example.com:443 to https://example.com:443 https://example.com:443 type redirects and what those can provide. The "why/value" is usually in clearly handling accidents in hardcoding connection info, particularly for local API/webdev environments where you might pass connection information as an object/list of parameters rather than normal user focused browser URL bar entry. The upside is a connection error can be a bit more opaque than an explicit 400 or 302 saying what happened or where to go instead. That's the entire reason webservers tend to respond with an HTTP 400 in such scenarios in the first place. Like I said though, once I remembered this was more a "hacky" type solution to give an error than built-in protocol upgrade functionality I'm not so sure the small amount of juice would actually be worth the relatively complicated squeeze for such a tool anymore.

bangaladore 2y ago

I don't think that really applies here. In general the way that works is user navigates to http://contoso.com http://contoso.com which implicitly uses port 80. Contoso server/cdn listening on port 80 redirects them through whatever means to https://contoso.com https://contoso.com which implicitly uses 443. I don't see value on both being on the same port. Why would I ever want to support this when the http: or https: essentially defines the default port. Now ofcourse someone could go to http://contoso.com:443 http://contoso.com:443, but WHY would they do this. Again, failing to see a reason for this.

zamadatix 2y ago
I (and the provided link) are not referring to http://example.com:80 http://example.com:80 to https://example.com:443 https://example.com:443 type redirects, though those are certainly nice too. They are, indeed, solely about http://example.com:443 http://example.com:443 to https://example.com:443 https://example.com:443 type redirects and what those can provide. The "why/value" is usually in clearly handling accidents in hardcoding connection info, particularly for local API/webdev environments where you might pass connection information as an object/list of parameters rather than normal user focused browser URL bar entry. The upside is a connection error can be a bit more opaque than an explicit 400 or 302 saying what happened or where to go instead. That's the entire reason webservers tend to respond with an HTTP 400 in such scenarios in the first place. Like I said though, once I remembered this was more a "hacky" type solution to give an error than built-in protocol upgrade functionality I'm not so sure the small amount of juice would actually be worth the relatively complicated squeeze for such a tool anymore.