Fix typos, spelling issues, and grammar in docs (#426)
This commit is contained in:
parent
9bbd0409ab
commit
b65bce5924
@ -109,7 +109,7 @@ The httpx project relies on these excellent libraries:
|
||||
|
||||
A huge amount of credit is due to `requests` for the API layout that
|
||||
much of this work follows, as well as to `urllib3` for plenty of design
|
||||
inspiration around the lower level networking details.
|
||||
inspiration around the lower-level networking details.
|
||||
|
||||
<p align="center">— ⭐️ —</p>
|
||||
<p align="center"><i>HTTPX is <a href="https://github.com/encode/httpx/blob/master/LICENSE.md">BSD licensed</a> code. Designed & built in Brighton, England.</i></p>
|
||||
|
||||
@ -42,7 +42,7 @@ assert r.status_code == 200
|
||||
assert r.text == "Hello World!"
|
||||
```
|
||||
|
||||
For some more complex cases you might need to customize the WSGI or ASGI
|
||||
For some more complex cases, you might need to customize the WSGI or ASGI
|
||||
dispatch. This allows you to:
|
||||
|
||||
* Inspect 500 error responses, rather than raise exceptions, by setting `raise_app_exceptions=False`.
|
||||
@ -70,9 +70,9 @@ make modifications before sending the request.
|
||||
<Response [200 OK]>
|
||||
```
|
||||
|
||||
## Specify the version of HTTP protocol
|
||||
## Specify the version of the HTTP protocol
|
||||
|
||||
One can set the version of HTTP protocol for the client in case you want to make the requests using specific version.
|
||||
One can set the version of the HTTP protocol for the client in case you want to make the requests using a specific version.
|
||||
|
||||
For example:
|
||||
|
||||
@ -157,6 +157,6 @@ proxy = httpx.HTTPProxy(
|
||||
)
|
||||
client = httpx.Client(proxies=proxy)
|
||||
|
||||
# This request will be tunnelled instead of forwarded.
|
||||
# This request will be tunneled instead of forwarded.
|
||||
client.get("http://example.com")
|
||||
```
|
||||
|
||||
@ -6,7 +6,7 @@ This documentation outlines places where the API differs...
|
||||
|
||||
## QuickStart
|
||||
|
||||
Pretty much all the API mentioned in the `requests` QuickStart should be identical
|
||||
Pretty much any API mentioned in the `requests` QuickStart should be identical
|
||||
to the API in our own documentation. The following exceptions apply:
|
||||
|
||||
* `Response.url` - Returns a `URL` instance, rather than a string. Use `str(response.url)` if you need a string instance.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Contributing
|
||||
|
||||
Thank you for being interested in contributing with HTTPX.
|
||||
There are many ways you can contribute with the project:
|
||||
Thank you for being interested in contributing to HTTPX.
|
||||
There are many ways you can contribute to the project:
|
||||
|
||||
- Try HTTPX and [report bugs/issues you find](https://github.com/encode/httpx/issues/new)
|
||||
- [Implement new features](https://github.com/encode/httpx/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
|
||||
@ -59,7 +59,7 @@ We use [nox](https://nox.thea.codes/en/stable/) to automate testing, linting,
|
||||
and documentation building workflow. Make sure you have it installed
|
||||
at your system before starting.
|
||||
|
||||
Install nox with:
|
||||
Install `nox` with:
|
||||
|
||||
```shell
|
||||
$ python3 -m pip install --user nox
|
||||
@ -72,7 +72,7 @@ to keep it into an isolated environment:
|
||||
$ pipx install nox
|
||||
```
|
||||
|
||||
Now, with nox installed run the complete pipeline with:
|
||||
Now, with nox installed, run the complete pipeline with:
|
||||
|
||||
```shell
|
||||
$ nox
|
||||
|
||||
@ -103,7 +103,7 @@ The HTTPX project relies on these excellent libraries:
|
||||
|
||||
A huge amount of credit is due to `requests` for the API layout that
|
||||
much of this work follows, as well as to `urllib3` for plenty of design
|
||||
inspiration around the lower level networking details.
|
||||
inspiration around the lower-level networking details.
|
||||
|
||||
## Installation
|
||||
|
||||
|
||||
@ -37,15 +37,14 @@ as soon as it's available:
|
||||
|
||||
## Exceptions and Cancellations
|
||||
|
||||
The style of using `parallel` blocks ensures that you'll always have well
|
||||
defined exception and cancellation behaviours. Request exceptions are only ever
|
||||
raised when calling either `get_response` or `next_response`, and any pending
|
||||
requests are cancelled on exiting the block.
|
||||
The style of using `parallel` blocks ensures that you'll always have a well-defined exception and cancellation behaviors. Request exceptions are only ever
|
||||
raised when calling either `get_response` or `next_response` and any pending
|
||||
requests are canceled on exiting the block.
|
||||
|
||||
## Parallel requests with a Client
|
||||
|
||||
You can also call `parallel()` from a client instance, which allows you to
|
||||
control the authentication or dispatch behaviour for all requests within the
|
||||
control the authentication or dispatch behavior for all requests within the
|
||||
block.
|
||||
|
||||
```python
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
The `httpx` library is designed to be API compatible with `requests` wherever
|
||||
possible.
|
||||
|
||||
First start by importing HTTPX:
|
||||
First, start by importing HTTPX:
|
||||
|
||||
```
|
||||
>>> import httpx
|
||||
@ -62,7 +62,7 @@ URL('https://httpbin.org/get?key1=value1&key2=value2&key2=value3')
|
||||
|
||||
## Response Content
|
||||
|
||||
HTTPX will automatically handle decoding the response content into unicode text.
|
||||
HTTPX will automatically handle decoding the response content into Unicode text.
|
||||
|
||||
```python
|
||||
>>> r = httpx.get('https://www.example.org/')
|
||||
@ -128,7 +128,7 @@ To include additional headers in the outgoing request, use the `headers` keyword
|
||||
## Sending Form Encoded Data
|
||||
|
||||
Some types of HTTP requests, such as `POST` and `PUT` requests, can include data
|
||||
in the request body. One common way of including that is as form encoded data,
|
||||
in the request body. One common way of including that is as form-encoded data,
|
||||
which is used for HTML forms.
|
||||
|
||||
```python
|
||||
@ -198,7 +198,7 @@ of items for the file value:
|
||||
|
||||
## Sending JSON Encoded Data
|
||||
|
||||
Form encoded data is okay if all you need is simple key-value data structure.
|
||||
Form encoded data is okay if all you need is a simple key-value data structure.
|
||||
For more complicated data structures you'll often want to use JSON encoding instead.
|
||||
|
||||
```python
|
||||
@ -222,7 +222,7 @@ For more complicated data structures you'll often want to use JSON encoding inst
|
||||
|
||||
## Sending Binary Request Data
|
||||
|
||||
For other encodings you should use either a `bytes` type, or a generator
|
||||
For other encodings, you should use either a `bytes` type or a generator
|
||||
that yields `bytes`.
|
||||
|
||||
You'll probably also want to set a custom `Content-Type` header when uploading
|
||||
@ -291,10 +291,10 @@ The `Headers` data type is case-insensitive, so you can use any capitalization.
|
||||
'application/json'
|
||||
```
|
||||
|
||||
Multiple values for a single response header are represented as a single comma separated
|
||||
Multiple values for a single response header are represented as a single comma-separated
|
||||
value, as per [RFC 7230](https://tools.ietf.org/html/rfc7230#section-3.2):
|
||||
|
||||
> A recipient MAY combine multiple header fields with the same field name into one “field-name: field-value” pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma.
|
||||
> A recipient MAY combine multiple header fields with the same field name into one “field-name: field-value” pair, without changing the semantics of the message, by appending each subsequent field-value to the combined field value in order, separated by a comma.
|
||||
|
||||
## Cookies
|
||||
|
||||
@ -329,7 +329,7 @@ with additional API for accessing cookies by their domain or path.
|
||||
|
||||
## Redirection and History
|
||||
|
||||
By default HTTPX will follow redirects for anything except `HEAD` requests.
|
||||
By default, HTTPX will follow redirects for anything except `HEAD` requests.
|
||||
|
||||
The `history` property of the response can be used to inspect any followed redirects.
|
||||
It contains a list of all any redirect responses that were followed, in the order
|
||||
|
||||
Loading…
Reference in New Issue
Block a user