launchpad proxy support

[Vincent Ladeuil]

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

    Gordon> Vincent Ladeuil wrote:
    >> Argh ! Gimme the headers ! :-)

    Gordon> Sorry, I didn't want to spam huge amounts of text. Here you go:

No problem :)

    Gordon> 0.219  * About to connect() to localhost:3128(proxy for
    Gordon> xmlrpc.edge.launchpad.net)
    Gordon> 0.234  > CONNECT xmlrpc.edge.launchpad.net
    Gordon> 0.234  > Host: localhost:3128
    >> Accept: */*
    >> User-Agent: bzr/2.1.0dev2 (urllib)
    >> Connection: Keep-Alive
    >> Pragma: no-cache
    >> Cache-Control: max-age=0

    Gordon> 0.250  < HTTP/1.1 502 Proxy Error ( The parameter is incorrect.  )

The most important one I wanted... but no enlightenment there :-/

<snip/>

    >> We can ask the reverse question: how come some proxies connect
    >> successfully without the port explicitly mentioned ?
    >> 
    >> I.e. on jaunty I see that same 'CONNECT
    >> xmlrpc.edge.launchpad.net' without port and the connection
    >> succeeds...

    Gordon> I was wondering that myself so I went and tested your
    Gordon> branch on my debian box at home using tinyproxy and
    Gordon> it worked. Color me extremely confused.

As I understood it, you too had your version working before going
too much into propagating the port, no ?

May be you didn't test the same *revno* at work and at home ?
revno 4781 added the port.

    Gordon> When I tested my changes to use the _urllib2_wrappers
    Gordon> but without the port correction, it was
    Gordon> failing.

At home or at work ?

    Gordon> There's something we're missing here...

Well, I can say for sure that httplib and urllib2 are very easy
to get confused with. _urllib2_wrappers implements a lot of
additional features *AND* fix many bugs encountered along the
way, the result is... feature-complete as far as bzr is
concerned, but I'd really like to rewrite the whole lot as an
enhanced httplib and get rid of the recursive call chains in the
Opener objects...

    >> But anyway, those are just debug outputs they can lie :-)

    Gordon> The thought had occurred to me as well.

Nah, I was kidding, but the fact is that the proxy is supposed to
receive only what we've seen, the request line 'CONNECT...' and
the headers. And indeed, I can't see how the proxy can deduce the
port from that... on the other hand CONNECT makes sense only for
https (since that's needed for the ssl wrapping), so...

    >> I now understand the intent of that controversial code, I've just
    >> pushed the equivalent fix, can you retry ?

    Gordon> It appears to be working in both of my test environments. I
    Gordon> noticed that in the tinyproxy environment, the tinyproxy log now
    Gordon> shows:

    Gordon> CONNECT   Oct 30 14:20:18 [24520]: Request (file descriptor 7):
    Gordon> CONNECT xmlrpc.edge.launchpad.net:443 HTTP/1.1

    Gordon> So it wasn't lying earlier. Very strange.

But you confirm that the fix works right ?

The code I pushed *set* the port so it should be displayed like that.

    Gordon> By the way, I noticed that you're using self.port in
    Gordon> the _urllib2_wrappers Request class to check if the
    Gordon> URL contains a port. I could not find where that was
    Gordon> being initialized when I was making my fix yesterday
    Gordon> which is why I had that code wart to rip the port out
    Gordon> of the original URL.

Grr, damn it, again. Non-sense, the port attribute is never used
in Request objects, it always stays in the host (as 'host:port')
but not in the xxConnections objects of course that would be too
simple.

The code is correct though, self.port is *always* None :)

Thanks for the heads-up !

       Vincent