launchpad proxy support
v.ladeuil+lp at free.fr
Fri Oct 30 21:03:58 GMT 2009
>>>>> "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> 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 :-/
>> 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
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
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
>> 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> CONNECT Oct 30 14:20:18 : 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
The code is correct though, self.port is *always* None :)
Thanks for the heads-up !
More information about the bazaar