While debugging an issue I discovered requests was coming back with 200
response, when it really shouldn't have. It turns out this happened for
two reasons: the jetty server running the app was rather lame and
didn't fail the request as a Bad Request, and httplib was happy to let
malformed data through and call it success.
It turns out httplib's strict flag controls this behavior of whether or
not to validate the status line. The underlying urllib3 supports the
concept as well. There was a bug there to that is now fixed upstream.
The last step is exposing this through requests. This introduces a
supports_http0.9 flag to help control this behavior. It defaults to
to True to preserve the current behavior. Setting it to False will
allow the underlying HTTPConnection to validate the status line.
Related to Issue #910. Specifically, OAuth won't sign the request unless
it gets a body type that is urlencoded or multipart. This is overly
restrictive. The correct behaviour is to sign the message without
including the body as part of the signature.
This will permit the deletion of just that one file in order
to fall back to the [probably more accurate but less consistent]
Distro provided CA certs.
JSON *must* be encoded using UTF-8, UTF-16 or UTF-32 (see the [RFC][1]; detect the encoding based on the fact that JSON always starts with 2 ASCII characters.
[1]: http://tools.ietf.org/html/rfc4627#section-3
compat.py: relevant imports added
utils.py: then those imports are imported here.
Nothing else was changed, but I saw mentions of quoting later in
utils.py but I wasnt sure what to do about that.
This replaces the sys.path hack with a slightly less objectionable
sys.modules hack.
Both have the effect of making the vendored lib's absolue imports work
as expected when oauthlib isn't installed. The sys.modules hack doesn't
insert the rest of the vendored crap in a global path, however.
Kenneth Reitz