I noticed that the exception printed in the previous commit started on the same
line as the print for the `str(e)` case right before it. Since this also prints
the content of urllib2.URLError.read(), it seems better to remove any existing
newline and re-add it, than to just assume the `str(e)` case was the only
problem.
If `ui.traceback=True` is set on the server, this prints the stacktrace for the
exception on the client side. Otherwise, nothing happens. I tried allowing the
exception to propagate back to Mercurial, but then the client sees this message
with 4.4.2 and 4.6.1:
abort: remote error:
Mercurial/Python process ends with return code 1
Something odd changed when upgrading from CentOS 7.4 to 7.5 around forwarding
requests from the loopback address that I don't fully understand. First, we
were getting a ValueError from inside `opener.open()` saying that 'localhost'
didn't match the host listed in the SSL certificate. That wasn't visible until
adding this.
Then what happened is a connection refused out of the same function, so the
traceback is added to the other handler too. Running the equivalent command on
the command line from the 'vcs' host stopped working in 7.5:
$ curl https://vcs.domain.com/hook/hg/?ping=true
curl: (7) Failed connect to vcs.domain.com:443; Connection refused
But it works when run on another machine targeting that same 'vcs' host. Adding
another firewall rule allows everything to work from the 'vcs' host again:
$ iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 8443
