|
1 | 1 | --- |
2 | 2 | layout: reports |
3 | | -title: "September 2021" |
| 3 | +title: "August 2021" |
4 | 4 | --- |
5 | 5 |
|
6 | | -## Weeknotes: Friday 3rd September, 2021. |
| 6 | +## Weeknotes: Friday 6th August, 2021. |
| 7 | + |
| 8 | + #### HTTPCore |
| 9 | + |
| 10 | + I've been putting more work into the [revised version of `httpcore`][0]. |
| 11 | + |
| 12 | + The repository now includes a simple README which is starting to outline how the interface looks... |
| 13 | + |
| 14 | + ```python |
| 15 | + import httpcore |
| 16 | + response = httpcore.request("GET", "https://www.example.com/") |
| 17 | + print(response) |
| 18 | + # <Response [200]> |
| 19 | + print(response.status) |
| 20 | + # 200 |
| 21 | + print(response.headers) |
| 22 | + # [(b'Accept-Ranges', b'bytes'), (b'Age', b'557328'), (b'Cache-Control', b'max-age=604800'), ...] |
| 23 | + print(response.content) |
| 24 | + # b'<!doctype html>\n<html>\n<head>\n<title>Example Domain</title>\n\n<meta charset="utf-8"/>\n ...' |
| 25 | + ``` |
| 26 | + |
| 27 | + I've also [opened an issue][1] which sketches out my plans for the documentation and API. |
| 28 | + |
| 29 | + What I'm particularly excited about here is the way that the design will allow you to drop into the network stack at various layers. I think the fundamentals of the design are going to make it much easier for developers to properly dig into and understand how the connection pooling works, and what's happening at each layer. |
| 30 | + |
| 31 | + For example: |
| 32 | + |
| 33 | + * Being able to examine the connections within the connection pool, and see what state each of them are in. |
| 34 | + * Being able to work directly with individual HTTP connections, and get a better understanding of the different states an HTTP connection can be in. |
| 35 | + * Being able to work directly at the network layer, or customise the network backend in order to perform logging, record/replay, network mocking, and other advanced functionality. |
| 36 | + |
| 37 | + #### HTTPX |
| 38 | + |
| 39 | + I've started drawing up a potential kickstarter to launch alongside the HTTPX 1.0 release. This has also helped me start to clarify what the roadmap for HTTPX ought to look like. |
| 40 | + |
| 41 | + * Issuing an HTTPX 1.0 release. I've outlined my thoughts on [final blockers to this][2]. |
| 42 | + * An HTTPX 1.1 release, alongside an updated HTTPCore. |
| 43 | + * An HTTPX 1.2 release, including an integrated command line client. |
| 44 | + |
| 45 | + #### Django REST framework |
| 46 | + |
| 47 | + I've made a tentative start on re-committing to a little more time on REST framework, by working through a couple of existing issues and discussions. |
| 48 | + |
| 49 | + Really the project could do with having 1-day-a-week of my time dedicated to it. |
| 50 | + |
| 51 | + I made the mistake this week of earmarking Friday for that work. In coming weeks I think it'd work better to have it be at the start of the week, since I think that'd help keep it prioritised. |
| 52 | + |
| 53 | + [0]: https://github.com/tomchristie/httpcore-the-directors-cut |
| 54 | + [1]: https://github.com/tomchristie/httpcore-the-directors-cut/issues/3 |
| 55 | + [2]: https://github.com/encode/httpx/issues/947#issuecomment-893576096 |
| 56 | + |
| 57 | + ## Weeknotes: Friday 13th August, 2021. |
| 58 | + |
| 59 | + The most significant piece of work this week has been re-assessing the automatic charset decoding policy in HTTPX. |
| 60 | + |
| 61 | + When an HTTP response is returned it'll generally have a `Content-Type` header indicating if the response is a text document, such as `text/html`, or a binary file, such as `image/jpg`. For textual content we need to pick a character set to use in order to decode the raw binary content into a unicode string. |
| 62 | + |
| 63 | + Ideally the server will indicate which encoding is being used within the `Content-Type` header, with a value such as `text/html; charset=utf-8`. However, the `charset` parameter isn't always present, and we need a policy to determine what to do in these cases. |
| 64 | + |
| 65 | + Previously we'd adopted a keep-it-simple policy in `httpx`, and attempted `utf-8` with fallbacks to other common encodings, but having been prompted to re-assess this, it seemed worth some time taking an evidence led approach onto determining what decoding policy to use. |
| 66 | + |
| 67 | + In [this repository](https://github.com/tomchristie/top-1000) I've taken a list of 1000 most accessed websites, and saved the downloaded content and response headers. Of these sites... |
| 68 | + |
| 69 | + * ~75% Included a Content-Type header complete with an explicit charset. |
| 70 | + * ~20% Did not include a charset, and decoded okay with `utf-8`. |
| 71 | + * ~5% Did not include a charset, and did not docode okay with `utf-8`. |
| 72 | + |
| 73 | + Based on these results we've decided to reintroduce automatic charset detection for cases that don't include a `charset` parameter. The results also demonstated sufficiently that the newer `charset_normalizer` package performed as well or better than `chardet` at detection, while being significantly faster. |
| 74 | + |
| 75 | + ## Weeknotes: Friday 20th August, 2021. |
| 76 | + |
| 77 | + Released HTTPX 0.19 |
| 78 | + |
| 79 | + ### Added |
| 80 | + |
| 81 | + * Add support for `Client(allow_redirects=<bool>)`. |
| 82 | + * Add automatic character set detection, when no `charset` is included in the response `Content-Type` header. |
| 83 | + |
| 84 | + ### Changed |
| 85 | + |
| 86 | + * Event hooks are now also called for any additional redirect or auth requests/responses. |
| 87 | + * Strictly enforce that upload files must be opened in binary mode. |
| 88 | + * Strictly enforce that client instances can only be opened and closed once, and cannot be re-opened. |
| 89 | + * Drop `mode` argument from `httpx.Proxy(..., mode=...)`. |
| 90 | + |
| 91 | + ## Weeknotes: Friday 27th August, 2021. |
| 92 | + |
| 93 | + **Holiday.** |
0 commit comments