From: Florimond Manca Date: Sun, 6 Dec 2020 00:16:59 +0000 (+0100) Subject: Document content encoding differences with Requests (#1416) X-Git-Tag: 0.17.0~22 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7ea6019c7068e1bb871592dc47621a157bc78aba;p=thirdparty%2Fhttpx.git Document content encoding differences with Requests (#1416) * Document content encoding differences with Requests * Apply suggestions from code review * Tweak copy for Windows-1252 Co-authored-by: Jamie Hewland Co-authored-by: Jamie Hewland --- diff --git a/docs/compatibility.md b/docs/compatibility.md index ea625a62..56476711 100644 --- a/docs/compatibility.md +++ b/docs/compatibility.md @@ -31,6 +31,12 @@ httpx.post(..., data={"message": "Hello, world"}) If you're using a type checking tool such as `mypy`, you'll see warnings issues if using test/byte content with the `data` argument. However, for compatibility reasons with `requests`, we do still handle the case where `data=...` is used with raw binary and text contents. +## Content encoding + +HTTPX uses `utf-8` for encoding `str` request bodies. For example, when using `content=` the request body will be encoded to `utf-8` before being sent over the wire. This differs from Requests which uses `latin1`. If you need an explicit encoding, pass encoded bytes explictly, e.g. `content=.encode("latin1")`. + +For response bodies, assuming the server didn't send an explicit encoding then HTTPX will do its best to figure out an appropriate encoding. Unlike Requests which uses the `chardet` library, HTTPX relies on a plainer fallback strategy (basically attempting UTF-8, or using Windows-1252 as a fallback). This strategy should be robust enough to handle the vast majority of use cases. + ## Status Codes In our documentation we prefer the uppercased versions, such as `codes.NOT_FOUND`, but also provide lower-cased versions for API compatibility with `requests`.