We have to pass urllib3 the url without the authentication information,
else it will be parsed by httplib as a netloc and included in the request line
and Host header
os.path.expanduser can raise a KeyError when $HOME is not set and the
POSIX getpwuid() call fails, which can happen when running under a UID
which is not in /etc/passwd or when the password file cannot be read.
The upstream bug report http://bugs.python.org/issue20164 is unlikely to
be backported to Python 2.x even if fixed so this change handles
KeyError by skipping netrc authentication.
Closes#1846
Added a check for 'getvalue' attr, calling it to retrieve the length if we can.
We also try/except the fileno() call, which can throw
io.UnsupportedOperation for BytesIO because, well, they're not files.
This has the added benefit of including proxies defined by the OS X System Configuration framework and in the Windows registry, rather than only checking os.environ.
Fixes#649 and #1329 by making Session.headers a CaseInsensitiveDict,
and fixing the implementation of CID. Credit for the brilliant idea
to map `lowercased_key -> (cased_key, mapped_value)` goes to
@gazpachoking, thanks a bunch.
Changes from original implementation of CaseInsensitiveDict:
1. CID is rewritten as a subclass of `collections.MutableMapping`.
2. CID remembers the case of the last-set key, but `__setitem__`
and `__delitem__` will handle keys without respect to case.
3. CID returns the key case as remembered for the `keys`, `items`,
and `__iter__` methods.
4. Query operations (`__getitem__` and `__contains__`) are done in
a case-insensitive manner: `cid['foo']` and `cid['FOO']` will
return the same value.
5. The constructor as well as `update` and `__eq__` have undefined
behavior when given multiple keys that have the same `lower()`.
6. The new method `lower_items` is like `iteritems`, but keys are
all lowercased.
7. CID raises `KeyError` for `__getitem__` as normal dicts do. The
old implementation returned
6. The `__repr__` now makes it obvious that it's not a normal dict.
See PR #1333 for the discussions that lead up to this implementation