On Python 3, response.msg.keys() contains the same value multiple times if
there are multiple headers with the same value. Work around this by
converting to a set before iterating over it.
There is a weird quirk in HTTP. You can send the same header twice.
For this reason, headers are represented by a dict, with lists as the
values. However, it appears that HTTPlib is completely incapable of
sending the same header twice. This puts me in a weird position: I want
to be able to accurately represent HTTP headers in cassettes, but I
don't want the extra step of always having to do [0] in the general
case, i.e. request.headers['key'][0]
In addition, some servers sometimes send the same header more than once,
and httplib *can* deal with this situation.
Futhermore, I wanted to keep the request and response cassette format as
similar as possible.
For this reason, in cassettes I keep a dict with lists as keys, but once
deserialized into VCR, I keep them as plain, naked dicts.
Before this change, vcrpy would not work with modules of Boto (e.g., boto.iam)
that use Boto's CertValidatingHTTPSConnection to connect to AWS (unless you
went through the extra effort of disabling certificate validation during the
tests). This change adds support for those modules.
So the stubs were getting out of hand, and while trying to add support for the
putrequest and putheader methods, I had an idea for a cleaner way to handle
the stubs using the VCRHTTPConnection more as a proxy object. So
VCRHTTPConnection and VCRHTTPSConnection no longer inherit from HTTPConnection
and HTTPSConnection. This allowed me to get rid of quite a bit of
copy-and-pasted stdlib code.
This is a backwards-incompatible change that will store headers
as a list rather than a dictionary. The reason being that you can
have multiple values for a single header, and concatenating them
together with commas can create an unparseable string (sometimes
the header values can have commas in them)
`responses_of` replaces `response_of`, since each request can have
several matching responses now.
This breaks backwards compatibility if you are using the
response_of method, so a version bump will be required.
