This test will fail with the following error:
TypeError: unbound method __init__() must be called with VCRHTTPConnection
instance as first argument (got CertValidatingHTTPSConnection instance instead)
The TypeError is raised because the __init__ method of Boto's
CertValidatingHTTPSConnection (which extends httplib.HTTPConnection) calls
httplib.HTTPConnection.__init__, and during the test httplib.HTTPConnection
actually refers to the patched verison (i.e., VCRHTTPConnection). When
VCRHTTPConnection.__init__ is called, it expects to receive a
VCRHTTPConnection object as its first argument, but instead it receives a
CertValidatingHTTPSConnection object. Because the only ancestor class of
CertValidatingHTTPSConnection is the original, un-patched
httplib.HTTPConnection, the first argument is not considered to be a
VCRHTTPConnection object, so a TypeError is raised.
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)
I wasn't emulating the stateful file-object in my response stub,
so urllib3 wasn't decompressing gzipped bodies properly. This
should fix that problem.
Thanks @bryanhelmig for the motivation to dig into this.
This commit not only changes the default method of matching requests
(just match on method and URI instead of the entire request + headers)
but also allows the user to add custom matchers.
This commit changes the whole core internal flow of requests.
Now, requests are actually physically made lazily when a response
is requested. This allows the entire request to be sent at once.
Otherwise, it would be impossible to compare whether requests have
already been recorded, since httplib.send() allows you to effectively
stream requests over HTTP.
Let's not use Google to test redirects since it changes depending on your
geographic location. I changed the test to use httpbin.org, since
a lot of our tests already depend on httpbin.org anyway.
Somedays, I'd like to implement my own local mock HTTP server I
can do asserts against. The test suite would just start it up,
and the server would record the requests, which I could then
retrieve and compare.
Closes#21
