launchpad proxy support

[Vincent Ladeuil]

>>>>> "Gordon" == Gordon Tyler <gordon at doxxx.net> writes:

    Gordon> Vincent Ladeuil wrote:
    >> Hmm, I was wrong, now that I've looked at the code
    >> _urllib2_wrappers can even take care of that...
    >> 
    >> >> You want to look at test_http among others, but be aware that we
    >> >> *don't* have a proxy test server, we fake one for test purposes
    >> >> but I don't think you can reuse it.
    >> 
    Gordon> Hmm... Why do I think the tests are going to be the hardest part
    Gordon> of all this? ;)
    >> 
    >> Yeah, that's why I delayed fixing that bug so long :-/
    >> 
    >> I'll have a simple fix with tests shortly, 

    Gordon> I've got some refactored code which puts the transport classes in
    Gordon> lp_registration.py, with a little abstraction to separate HTTP
    Gordon> from HTTPS, which I can push up to lp later this evening if you
    Gordon> want. I was trying to separate the code paths but I hit the snag
    Gordon> in the urllib2 wrappers that you probably found.

I didn't touch the wrappers at all (well, except to take into
account the report_activity problems you noticed).

Can you give a try at lp:~vila/bzr/186920-lp-proxy and give me
feedback about whether it fixes the bug for you ?

I think the problems you encountered may be related to proxy
redirecting http to https or the reverse, be sure to set
https_proxy if you want to reach launchpad (or all_proxy) or
simply because you tried to handle the default port explicitly,
which we tried, failed, and abandoned in other areas :-)

I tested locally with tinyproxy on a jaunty host with:

  https_proxy=http://localhost:8888 ./bzr lp-open -Dhttp lp:bzr

You can then look into ~/.bzr.log to check that the connection is
done to the proxy (search for messages like: "* About to connect()
to localhost:8888(proxy for xmlrpc.edge.launchpad.net")

I didn't truly test the proxy handling though, but I tested the
new stack so I think that's enough for the fix.

    Vincent