Enabling this is trivial, the question is: is there any reason we *can't* enable this? Who's responsible for this service and might know of exceptions like mixed-content, or HTTPS-incapable tools which rely on it, etc? [note this a generic message being tacked into the description of several similar tickets]
As gitblit is on the chopping block for deprecation anyways, my inclination is to go ahead and enable HTTPS for this soon and see if anyone screams, unless someone has a known reason we shouldn't!
In lieu of anything more-concrete to go on, I've been monitoring the varnishlog live request flow for git.wikimedia.org this morning. The basic analysis of that is:
- The traffic rate is *extremely* low. There are occasional bursts when some user hits the web UI with a browser, but not often (probably owing to the horrible UX because it's very very slow). Aside from rare browsers that should be able to cope with the redirect fine, we've got:
- neon doing nagios check_http calls. I've look at that, and it will still return OK for the 301.
- One oddball client on some hosting service provider, which has a UA string of Mozilla/8.0 (Windows 2008 SP32 + 3patch) and tends to occasionally access URLs of the form /blob/operations/dumps.git/ariel/xmldumps-backup/.... That UA string is pretty non-standard and uninformative. It may or may not be able to follow an HTTPS redirect, but can check logs after flipping the switch and see if it seems to or not.