mureq
is a single-file, zero-dependency alternative to python-requests, intended to be vendored in-tree by Linux systems software and other lightweight applications. It is released under the 0BSD license to facilitate this (it can be freely copied without any attribution requirements).
>>> mureq.get('https://clients3.google.com/generate_204')
Response(status_code=204)
>>> response = _; response.status_code
204
>>> response.headers['date']
'Sun, 26 Dec 2021 01:56:04 GMT'
>>> response.body
b''
>>> params={'snap': 'certbot', 'interface': 'content'}
>>> response = mureq.get('http://snapd/v2/connections', params=params, unix_socket='/run/snapd.socket')
>>> response.status_code
200
>>> response.headers['Content-type']
'application/json'
>>> response.body
b'{"type":"sync","status-code":200,"status":"OK","result":{"established":[],"plugs":[],"slots":[]}}'
>>> response.json()
{'type': 'sync', 'status-code': 200, 'status': 'OK', 'result': {'established': [], 'plugs': [], 'slots': []}}
In short: performance (memory consumption), security (resilience to supply-chain attacks), and simplicity.
python-requests is extremely memory-hungry, mainly due to large transitive dependencies like chardet that are not needed by typical consumers. Here's a simple benchmark using Python 3.9.7, as packaged by Ubuntu 21.10 for amd64:
user@impish:~$ python3 -c "import os; os.system('grep VmRSS /proc/' + str(os.getpid()) + '/status')"
VmRSS: 7404 kB
user@impish:~$ python3 -c "import os, mureq; os.system('grep VmRSS /proc/' + str(os.getpid()) + '/status')"
VmRSS: 13304 kB
user@impish:~$ python3 -c "import os, mureq; mureq.get('https://www.google.com'); os.system('grep VmRSS /proc/' + str(os.getpid()) + '/status')"
VmRSS: 15872 kB
user@impish:~$ python3 -c "import os, requests; os.system('grep VmRSS /proc/' + str(os.getpid()) + '/status')"
VmRSS: 21488 kB
user@impish:~$ python3 -c "import os, requests; requests.get('https://www.google.com'); os.system('grep VmRSS /proc/' + str(os.getpid()) + '/status')"
VmRSS: 24352 kB
In terms of the time cost of HTTP requests, any differences between mureq and python-requests should be negligible, except in the case of workloads that use the connection pooling functionality of python-requests. Since mureq opens and closes a new connection for each request, migrating such a workload will incur a performance penalty. Note, however, that the normal python-requests API (requests.request
, requests.get
, etc.) also disables connection pooling, instead closing the socket immediately to prevent accidental resource leaks. In order to use connection pooling, you must explicitly create and manage a requests.Session object.
It's unclear to me whether connection pooling even makes sense in the typical Python context (single-threaded synchronous I/O, where there's no guarantee that the thread of control will re-enter the connection pool). It is much easier to implement this correctly in Go.
Together with its transitive dependencies, python-requests is tens of thousands of lines of third-party code that cannot feasibly be audited. The most common way of distributing python-requests and its dependencies is pypi.org, which has relatively weak security properties: as of late 2021 it supports hash pinning, but not code signing. Typical Python deployments with third-party dependencies are vulnerable to supply-chain attacks against pypi.org, i.e., compromises of user credentials on pypi.org (or of pypi.org itself) that allow the introduction of malicious code into their dependencies.
In contrast, mureq is approximately 350 lines of code that can be audited easily and included directly in a project. Since mureq's functionality is limited in scope, you should be able to "install" it and forget about it.
python-requests was an essential addition to the ecosystem when it was created in 2011, but that time is past, and now in many cases the additional complexity it introduces is no longer justified:
However, the API design of python-requests is excellent and in my opinion still considerably superior to that of urllib.request --- hence the case for a lightweight third-party library with a requests-like API.
mureq supports Python 3.6 and higher. Copy mureq.py
into a suitable directory of your project, then import as you would any other internal module, e.g. import .mureq
or import bar.baz.mureq
.
Supply-chain attacks are considerably mitigated simply by vendoring mureq (i.e. copying it into your tree). If you are also concerned about future attacks on this GitHub account (or GitHub itself), tagged releases of mureq will be signed with the GPG key 0x740FC947B135E7627D4D00F21996B89DF018DCAB
(expires 2025-07-28), or some future key in a chain of trust from it.
Vendoring mureq's tests is not recommended. The tests rely on third-party HTTP services, so including them in a project-specific test suite or CI/CD pipeline will reduce the reliability of your project's tests and also risks overburdening the third-party services.
The core API (mureq.get
, mureq.post
, mureq.request
, etc.) is similar to python-requests, with a few differences. For now, see the docstrings in mureq.py
itself for documentation. HTML documentation will be released later if there's a demand for it.
If you're switching from python-requests, there are a few things to keep in mind:
mureq.get
, mureq.post
, and mureq.request
mostly work like the analogous python-requests calls.mureq.HTTPResponse
, which exposes fewer methods and properties than requests.Response
. In particular, it does not have text
(since mureq doesn't do any encoding detection). Instead, the response body is in the body
member, which is always of type bytes
. (For the sake of compatibility, the content
property is provided as an alias for body
.)body
kwarg, which only accepts bytes
.json
kwarg takes an arbitrary object, which is serialized to JSON, encoded as UTF-8, and sent as the request body with the usual Content-Type: application/json
header.form
kwarg. This accepts a dictionary of key-value pairs, or any object that can be serialized by urllib.parse.urlencode. It will add the usual Content-Type: application/x-www-form-urlencoded
header.with mureq.yield_response(url, method, **kwargs)
. This yields a http.client.HTTPResponse. Exiting the contextmanager automatically closes the socket.max_redirects
, which takes an integer number of redirects to allow, e.g. max_redirects=2
.mureq.HTTPException
(which is actually just http.client.HTTPException) for any runtime I/O error (including invalid HTTP responses, connection failures, timeouts, and exceeding the redirection limit). It may throw other exceptions (in particular ValueError
) for programming errors, such as invalid or inconsistent arguments.unix_socket
kwarg, which overrides the hostname in the URL, e.g. mureq.get('http://snapd/', unix_socket='/run/snapd.socket')
http+unix
URL scheme, which take the percent-encoded path as the hostname, e.g. http+unix://%2Frun%2Fsnapd.socket/
to connect to /run/snapd.socket
.If I were you, I would be asking: given that python-requests is used successfully on millions of systems, who is this person touting a replacement?
I'm nobody special --- not a security expert, not an HTTP protocol expert --- just someone who has been dealing with problems in this ecosystem for years. That's just the thing: HTTP isn't that hard! HTTP is already safe for humans.