* Add a workflow to check documentations
* Fix markdown issues
* Install Ruby 2.7
* Finally, handle and fix GitHub templates
* Minor improvement in the feature request template
* Verbose mode to be sure all files are checked
* Split the monolithic workflow into specific ones
* Rename workflows, improve commands
* Update pip from the venv
* Fix Windows setup
* Lowercase macos-latest
* Fix Windows run, again
* Update brew formula to 2.5.0
* Can use `idna` 3.2
* Sort requirements to ease reproductible builds
And also to have the same output as `brew bump-formula-pr`.
* Sync `bottles` with official Formula
And keep the `high_sierra` one.
* Add a workflow to check the Formula
* Convert most of the documentation from the frontend `README.rst` to `docs/REAME.md`
Also converted all reStructuredText files to Markdown.
* Tell `mdformat` to use LF for end on lines
* `--check` is not needed in the help message
* Skip tests on GitHub Windows.
Those tests pass on a real Windows machine.
Let's revisit those failure later, if needed.
* Move `mdoformat` requirement from `test` to `dev` extra
To fix Fedora CI.
* Remove hashbang from bash completion
Completion files are not supposed to have a hashbang.
They are sourced, not executed.
* Fix spelling
* Trim excess whitespace
* Fix the handling of cookies from session files
* Apply suggestions from code review
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
* Fix test docstring formatting
Co-authored-by: Jakub Roztocil <jakub@roztocil.co>
By default, only updates that are propagated trough the Fedora's update system
will be available in the community Copr build system.
On stable Fedora releases,
updates (including new packages) might be delayed 1+ week.
This adds the latest Koji (that's the name of the official Fedora build system) repo.
That repo contains more recent packages available during the official Fedora builds.
The Koji repo is not mirrored,
so the Copr builds are more likely to encounter a network issue,
but I think it is worth it.
The `/packit build` command may be used in the pull request if this happens.
* 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>
