* Support `requests.response.raw` being a file-like object
Previously HTTPie relied on `requests.models.Response.raw` being
`urllib3.HTTPResponse`. The `requests` documentation specifies that
(requests.models.Response.raw)[https://docs.python-requests.org/en/master/api/#requests.Response.raw]
is a file-like object but allows for other types for internal use.
This change introduces graceful handling for scenarios when
`requests.models.Response.raw` is not `urllib3.HTTPResponse`. In such a scenario
HTTPie now falls back to extracting metadata from `requests.models.Response`
directly instead of direct access from protected protected members such as
`response.raw._original_response`. A side effect in this fallback procedure is
that we can no longer determine HTTP protocol version and report it as `1.1`.
This change is necessary to make it possible to implement `TransportPlugins`
without having to also needing to emulate internal behavior of `urlib3` and
`http.client`.
* Load cookies from `response.headers` instead of `response.raw._original_response.msg._headers`
`response.cookies` was not utilized as it not possible to construct original
payload from `http.cookiejar.Cookie`. Data is stored in lossy format. For example
`Cookie.secure` defaults to `False` so we cannot distinguish if `Cookie.secure` was
set to `False` or was not set at all. Same problem applies to other fields also.
* Simpler HTTP envelope data extraction
* Test cookie extraction and make cookie presentment backwards compatible
Co-authored-by: Mickaël Schoentgen <contact@tiger-222.fr>
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Immediatelly convert all args from `bytes` to `str`.
* Added `Environment.stdin_encoding` and `Environment.stdout_encoding`
* Allow unicode characters in HTTP headers and basic auth credentials
by encoding them using UTF8 instead of latin1 (#212).
In verbose mode, the basic auth user and password would show up in colored
output reporting the Host header, as reported in
https://github.com/jkbr/httpie/issues/169
E.g., this will only read the response headers but won't download the
whole file:
http GET --headers example.org/big-file.avi
The request method is respected (i.e., it doesn't switch to HEAD like
cURL does).
* Bodies of multipart requests are correctly printed (closes#30).
* Binary requests and responses should always work (they are also suppressed
for terminal output). So things like this work::
http www.google.com/favicon.ico > favicon.ico
