When redirecting a hit to the proper URL, word press makes some bad assumptions. Specifically, during redirects, any port information provided by the client is dropped. If I go to http://example.com:80/, I get redirected to http://example.com/. If I go to https://example.com:443/, I get redirected to https://example.com/.
Thus far, no problem has occured because we are on on server that uses default ports. However, lets say my webserver is running http on 8080 and https on 8443. Now when I go to http://example.com:8080/ and get redirected to http://example.com/, it fails. As a workaround, you can change the following settings:
WordPress address: http://example.com:8080/
Blog address: http://example.com:8080/
While this clears up the problem for http requests, you will not be able to use https becuase and attempt to go to https://example.com:8443/ now redirects to https://example.com:8080/ and it fails because the server does not speak ssl on 8080.
Additionally, when you have an https proxy in front of your webserver such as pound (with http on port 80 and https on port 8443), you run into another problem caused by this same bug. In this situation if you attempt to go to https://example.com/, the proxy server accepts the request and then on the back end makes a none ssl connection to apache. Good so far, but in order to not make any assumptions, the proxy server tells apache that the request was for 'https://example.com:443/' and apache sets HTTP_HOST (very appropriately) to example.com:443. WordPress sees this request and redirects it to 'https://example.com/' by responding to the web browser with a 'Location:' header. Thus the browser sends another request for 'https://example.com/' and starts the whole process over again resulting in an infinite redirect.
As specifying a port is completely vaild, this is a clear case of wordpress not handling things appropriately.
I've seen several other posts (and bug reports) about problems realted to this and they appear to have been shrugged off as being a configuration problem on the server side (and some of them really were). However, I believe the information / examples I've provided show cases where the servers are configured in a perfectly legitimate way (albeit not completely vanilla). Keep in mind that many clusters hosting solutions utilize an https proxy.
I attempted to file this as a bug, but my login is not currently working on trac.wordpress.org, so I was not able to.