The attached patch adds X-Forwarded-Proto and Front-End-Https support to Drupal.
Drupal detects whether it's using HTTPS by looking at $_SERVER['HTTPS']. This variable is of course not set to "YES" if Drupal runs in HTTP. If your Drupal site is behind an reverse proxy or load balancer that serves HTTPS to clients but communicates with the web server via HTTP (i.e. Internet --HTTPS--> ReverseProxy --HTTP--> Apache), Drupal infers an incorrect $base_root.
I've found two conventions for passing protocol information back to the web server from the load balancer. The more common strategy is to use an X-Forwarded-Proto (XFP) header as part of the request sent to the back-end web server, set to the protocol (HTTP or HTTPS). Pound (http://www.apsis.ch/pound) includes this natively, and the practice is growing to add this header line to Apache servers running mod_proxy_http so that back-end applications know what protocol to use.
The less common method is a Front-End-Https header used apparently only by "Microsoft Internet Security and Acceleration Server", and is documented generally in conjunction with getting Outlook Web Access to function properly (presumably since it also requires AJAX callbacks to have a correct URL).
Without a correct $base_root, various things break -- most visibly, AJAX including and the Drupal installer, because callback URLs are built on an incorrect $base_url.
The patch introduces one to three extra IF conditions to be evaluated for every HTTP request, unless $base_url has been overridden in settings.php. For the largest portion of users, who are not using a load balancer, the patch introduces only two conditions to be evaluated, one for each header variable.
It is possible to set $base_root manually in settings.php. But using this patch will allow Drupal to work in this sort of environment as it is already documented, without special care being taken to create settings.php ahead of time.
Also, I should point out that neither of the headers this patch detects are standard parts of HTTP. For details on Front-End-Https, see MS KB document Q307347 for details.
It's possible that protocol detection can be made in other ways as well. If you know of one (because you use a load balancer that does this differently), please comment!