GO — Healthy across all four use cases

• Last commit 3mo ago
• 40+ active contributors
• Distributed ownership (top contributor 36% of recent commits)
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 3mo ago
• ⚠ Scorecard: marked unmaintained (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

HTTPX is a next-generation HTTP client library for Python 3 that provides both synchronous and asynchronous APIs with integrated HTTP/1.1 and HTTP/2 support, plus a command-line interface. It solves the problem of having a modern, fully type-annotated HTTP client with built-in timeouts, streaming, and transport flexibility while maintaining API compatibility with the popular requests library. Monolithic package structure: httpx/ directory contains the main library code (with init.py and version.py at root), docs/ holds Markdown documentation for mkdocs generation, .github/workflows/ contains CI pipeline definitions, and examples/tests are typical Python package layout. No subpackages visible in top 60—single cohesive module.

Python developers building HTTP-based applications who need features like async/await support, HTTP/2, strict timeouts, direct WSGI/ASGI transport support, and full type hints—whether they're building REST API clients, CLI tools, or integrating with web frameworks.

This is a production-ready, actively maintained project with 100% test coverage (as stated in README), comprehensive CI/CD via GitHub Actions (.github/workflows/test-suite.yml and publish.yml), full documentation site (docs/ structure), and pinned tooling versions in requirements files. The codebase shows 570K+ lines of Python, indicating substantial maturity.

Low risk for a core HTTP client: the project pins development tooling strictly (as noted in requirements comments about 'environments we can strictly control') and uses 27 dependencies in the dev environment (cryptography, trio, uvicorn, trustme for testing). No single-maintainer risk is evident from the 'encode' organization structure. Breaking changes are managed via CHANGELOG.md and are typically well-announced for a HTTP library.

Active development visible through test suite automation (test-suite.yml), publishing pipeline (publish.yml), and Dependabot dependency updates (.github/dependabot.yml). Documentation is current (mkdocs-material 9.6.18, mkdocs 1.6.1). Recent tooling includes pytest 8.4.1, mypy 1.17.1, ruff 0.12.11—all recent 2024 versions suggesting ongoing maintenance.

git clone https://github.com/encode/httpx.git
cd httpx
pip install -e .[brotli,cli,http2,socks,zstd]
pip install -r requirements-dev.txt
pytest

Daily commands: For development: pytest runs tests (via pytest 8.4.1 in requirements). For linting: ruff check . and mypy httpx. For docs: mkdocs serve (mkdocs 1.6.1 installed). CLI usage: httpx https://example.org/ or python -m httpx after pip install.

• httpx/init.py: Exports all public API (Client, AsyncClient, Response, Request, etc.) and defines optional CLI dependencies
• httpx/version.py: Centralizes version management for package releases
• .github/workflows/test-suite.yml: Defines CI pipeline for running tests across Python versions and platforms before merge
• .github/workflows/publish.yml: Controls automated package publishing to PyPI on release tags
• docs/api.md: Primary API reference documentation generated from docstrings; entry point for users learning the library
• docs/advanced/transports.md: Documents the pluggable transport architecture (WSGI, ASGI, HTTP/2) that distinguishes httpx from requests
• docs/async.md: Covers async/await patterns and AsyncClient usage, a major feature differentiator
• README.md: Quick-start examples and feature overview; main entry point for prospective users
• .github/CONTRIBUTING.md: Contributor guidelines; must read before opening PRs or issues

Start in httpx/init.py to understand the public API surface. Core client logic is in httpx/ (not yet fully visible in top 60, but referenced). Add tests in tests/ following pytest conventions. Documentation changes go in docs/ (markdown files like docs/api.md, docs/async.md). For transport changes, see docs/advanced/transports.md and corresponding implementation.

HTTP/2 is optional and requires pip install httpx[http2] (h2 package); omitting this silently falls back to HTTP/1.1. SOCKS proxy support requires pip install httpx[socks]. Charset detection requires optional chardet==5.2.0 but only in dev tests. Strict timeouts are enforced everywhere—mutable timeout behavior differs from requests (no None for no timeout in httpx). WSGI/ASGI transports require the application to be importable; edge cases around thread safety exist.

• HTTP/2 Multiplexing — httpx transparently supports HTTP/2's ability to send multiple requests over a single connection simultaneously, improving performance for concurrent requests compared to HTTP/1.1
• Pluggable Transport Layer — httpx abstracts the underlying transport (TCP sockets, WSGI, ASGI) via a Transport interface, enabling direct in-process testing against web apps without network overhead
• Strict Timeout Enforcement — Unlike requests, httpx applies timeouts at all stages (connection, read, write, pool) with no None option for 'no timeout', preventing hanging connections by design
• Async Context Managers (AsyncClient) — httpx provides native async/await support with AsyncClient for high-concurrency I/O without thread overhead, essential for modern async Python frameworks
• Connection Pooling & Keep-Alive — httpx reuses TCP connections across multiple requests to reduce latency and improve throughput, with configurable pool sizes and timeout behaviors
• Streaming Requests & Responses — httpx allows iterative reading/writing of large payloads without buffering entire bodies in memory, critical for handling large files or streaming APIs
• Event Hooks System — httpx provides request/response lifecycle hooks for logging, authentication, metrics, and middleware patterns without intrusive monkey-patching

• psf/requests — HTTPX's spiritual predecessor and API compatibility baseline; understanding requests patterns helps grasp what httpx improves
• python-httpx/httpx-core — Core HTTP parsing logic shared across httpx ecosystem projects
• encode/starlette — Sister project from same organization; httpx's ASGI transport integrates directly with Starlette apps
• encode/databases — Companion library from encode that uses httpx for HTTP operations in async ORM contexts
• python-hyper/h2 — The HTTP/2 implementation httpx delegates to when [http2] extra is installed

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive tests for httpx/_urlparse.py module

The _urlparse.py module exists but there's no dedicated test file visible in the structure. URL parsing is critical for HTTP clients and needs extensive coverage for edge cases (internationalized domains, unusual port numbers, malformed URLs, etc.). This would improve robustness and prevent regressions.

• [ ] Create tests/test_urlparse.py with test cases for valid/invalid URLs
• [ ] Test edge cases: IDN domains, unusual ports, special characters in path/query
• [ ] Test against httpx/_urlparse.py functions directly
• [ ] Ensure coverage for all public functions in the module
• [ ] Run pytest to verify tests pass with current implementation

Add integration tests for httpx/_transports/wsgi.py and asgi.py

The WSGI and ASGI transport adapters (httpx/_transports/wsgi.py, asgi.py) are specialized transport implementations but likely lack comprehensive integration tests. These need testing against real WSGI/ASGI applications to ensure proper request/response handling, error cases, and streaming.

• [ ] Create tests/test_transports_wsgi.py with real WSGI app test cases
• [ ] Create tests/test_transports_asgi.py with real ASGI app test cases
• [ ] Test request/response headers, body streaming, and status codes
• [ ] Test error handling (malformed requests, app exceptions)
• [ ] Test with uvicorn (already in dependencies) for ASGI validation

Add missing documentation for httpx/_multipart.py multipart form encoding

The codebase has httpx/_multipart.py for handling multipart form data, but docs/advanced/ doesn't have a dedicated file explaining multipart requests, file uploads, or form data encoding. The API documentation is sparse. New contributors and users need clear examples.

• [ ] Create docs/advanced/multipart-forms.md with multipart form examples
• [ ] Document file upload patterns and streaming large files
• [ ] Add examples for setting custom headers in multipart boundaries
• [ ] Document chunking behavior and memory considerations
• [ ] Reference this new file from docs/api.md and docs/advanced/extensions.md

• Add type stub tests for the CLI argument parser in httpx/ to increase coverage of command-line interface code paths, which currently lacks dedicated tests visible in top 60
• Expand docs/troubleshooting.md with a 'Common Timeout Errors' section, since httpx enforces strict timeouts and receives user confusion—reference existing docs/advanced/timeouts.md
• Add integration test for WSGI transport in the test suite covering common Django/Starlette edge cases, as docs/advanced/transports.md exists but test coverage is unknown

The httpx codebase demonstrates good security hygiene with pinned development dependencies and a well-organized structure. No hardcoded secrets, injection vulnerabilities, or critical misconfigurations were detected in the provided file structure. The main recommendations are establishing a formal security policy, separating development dependencies, and maintaining regular dependency updates. The project's focus on testing and code quality (mypy, pytest, ruff) is a positive security indicator.

• Medium · Outdated Cryptography Dependency — requirements.txt. The requirements.txt pins cryptography==45.0.7, which may have known vulnerabilities. While pinning is good practice, regular updates are essential for security patches. Fix: Regularly update cryptography to the latest stable version and monitor security advisories from the cryptography project.
• Low · Development Dependencies in Single File — requirements.txt. The requirements.txt mixes development/testing dependencies (pytest, mypy, ruff, uvicorn) with optional package dependencies. This could lead to accidentally shipping development tools in production. Fix: Separate development dependencies into a requirements-dev.txt file and use proper package entry points in pyproject.toml for optional dependencies.
• Low · No Security Policy Documentation — Repository root. No visible SECURITY.md or security policy file in the repository for coordinated vulnerability disclosure. Fix: Create a SECURITY.md file documenting how users should report security vulnerabilities privately before public disclosure.
• Low · Unpinned Test Dependency Versions — requirements.txt. According to the comment in requirements.txt, some package dependencies are intentionally unpinned to test against latest versions. While this ensures compatibility, it could introduce unexpected breaking changes or security issues in CI/CD. Fix: Consider using version ranges (>=X.Y,<X+1.0) instead of completely unpinned versions to balance testing with stability.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/encode/httpx shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live encode/httpx repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/encode/httpx.

What it runs against: a local clone of encode/httpx — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in encode/httpx | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 121 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of encode/httpx. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/encode/httpx.git
#   cd httpx
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of encode/httpx and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "encode/httpx(\\.git)?\\b" \\
  && ok "origin remote is encode/httpx" \\
  || miss "origin remote is not encode/httpx (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 121 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~91d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/encode/httpx"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.