Cybjit <report@bugs.python.org> writes:
> Cybjit added the comment:
>
> On 2014-05-10 00:23, nikratio wrote:
>> Is pip maybe doing its own certificate check, and relying on
>> HTTPSConnection.host to contain the final hostname rather than the proxy?
>
> I think the culprit might be here
> https://github.com/pypa/pip/blob/1.5.4/pip/_vendor/requests/packages/urllib3/connection.py#L172

Yes, that's the problem. I guess that nicely demonstrates why using
inheritance as an API is not a good idea.

I guess we nevertheless need to repair/work around this in Python 3.4?
Unfortunately pip explicitly relies on _set_tunnel() to set self.host =
self._tunnel_host. So we would need to change _set_tunnel() to save the
original attribute somewhere, change the other methods to use the saved
attribute in favor of the real one, and have connect() restore it (so
that we can reconnect). This still would not allow pip to reconnect
(because it overwrites the connect method), but then reconnecting a
tunneled connection with pip did not work before either. Still, rather
ugly.

Alternatively, maybe we could also do nothing, because if pip is
depending on undocumented semantics of a private method (_set_tunnel),
they have to live with the consequences?

Thinking about this, I think we should just revert the entire patch for
3.4, but keep it in for 3.5. That gives the pip folks enough time to fix
their code. Fixing the issue in 3.4 is probably not that crucial (after
all, it existed since about 2.6.3).

Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«