CodeVetter
← All unpacks
CodeVetter · Repo Unpack evidence

encode/starlette

Scanned commit 4e7fc04e5f dated 2026-10-01 — last upstream commit. Generated by codevetter 1.15.0 on 2026-10-02.

github.com/encode/starlette ↗ · 143 files · 1.0 MB

[source preview omitted from public export]

Deep analysis by cli:codex via the codex CLI on 2026-10-02 (399s) — every claim below links to its cited source files. Source inspection; upstream code and tests were not executed.

Overview

Starlette is a Python ASGI framework and toolkit for developers building asynchronous HTTP and WebSocket services. At commit 4e7fc04e5f2c69f60e418ff2107d0f6d9a0fe423, its composable application, routing, middleware, request, and response objects support both complete applications and independently mounted components. AnyIO provides concurrency boundaries, while optional packages supply forms, templates, signed sessions, telemetry, and testing; Cloudflare configuration serves the documentation site.

System map

The runtime contract is ASGI: a server supplies a mutable scope and asynchronous receive/send channels. Starlette composes a router and middleware, while individual components can also act as ASGI applications. State is held in application or connection mappings, upload temporary files, and signed client cookies; database selection belongs to consuming applications. Packaging and documentation deployment are separate from serving developer applications.

Feature catalog

The public surface centers on developer APIs for composing web services. Routing supports function endpoints, endpoint classes, mounted applications, typed parameters, method restrictions, and reverse URLs. Requests, responses, WebSockets, rendering, authentication, and middleware provide the main service capabilities. Lifecycle handlers, background callbacks, configuration, and an in-process client complete the inspected toolkit.

Data flow

ASGI scope and message streams carry input through middleware and routing into connection objects. Parsing and rendering are generally lazy or explicit, with cached request bodies distinct from consumed streams. Uploads, lifespan state, and sessions have different ownership and cleanup boundaries. Outputs pass through send wrappers, which can modify headers, enforce limits, or collect telemetry before reaching the server.

Behavior traces

The inspected flows follow explicit protocol transitions rather than a standalone executable entrypoint. Startup establishes resources, HTTP routing adapts endpoints, and session persistence occurs when response headers start. Upload and static-file paths cross filesystem boundaries with distinct cleanup and containment rules. WebSocket and exception paths enforce state-dependent behavior that is material to callers.

Testing signals

Tests and CI were inspected, not executed; no passing result or measured coverage is established here. The inspected suite uses pytest, AnyIO backends, in-process TestClient calls, and direct ASGI message tests. Assertions cover lifecycle, body-limit branches, upload cleanup, file containment, ranges, sessions, and background execution. Coverage excludes selected branches, and this bounded inspection does not establish exhaustive scenario or deployment coverage.

Risk map

These findings are source observations and explicitly labeled hypotheses, not confirmed vulnerabilities. Material boundaries include optional body limits, client-readable signed sessions, filesystem serving, diagnostic output, and telemetry export. Middleware task boundaries and response-start state create compatibility-sensitive behavior. Existing tests cover several of these boundaries, but they were not executed during this inspection.

Extension points

Composition occurs through ordinary Python interfaces and ASGI callables. Route lists, converter registries, middleware factories, authentication backends, and lifespan context managers are explicit insertion points. Rendering and schema classes support specialization without replacing application dispatch. Optional integrations and mounted third-party applications keep concerns such as databases and GraphQL outside the core lifecycle.

Contributor handoff

This brief is based on bounded source inspection at the requested commit; tests, benchmarks, and CI were inspected, not executed. Start edits from the ASGI contract and the relevant implementation/test pair, then follow cross-module state and message ownership. Preserve differences between standalone components, composed applications, and server-supported extensions. Existing repository scripts define future validation, but the current task authorizes read-only inspection only.

Languages

LanguageFilesShare of source
Python8498%
Markdown32docs/config
YAML8docs/config
HTML3docs/config
TOML22%
CSS1docs/config

Start reading here

Probable source entrypoint: pyproject.toml — inferred from the directory tree and manifest, not the upstream docs.

Source roots

starlette/ (37 files)

Source layout — starlette/

PathFiles
starlette/middleware/13
starlette/__init__.py1
starlette/_exception_handler.py1
starlette/_utils.py1
starlette/applications.py1
starlette/authentication.py1
starlette/background.py1
starlette/concurrency.py1
starlette/config.py1
starlette/convertors.py1
starlette/datastructures.py1
starlette/endpoints.py1
starlette/exceptions.py1
starlette/formparsers.py1

Repository structure

Top-level pathFiles
starlette/37
tests/36
docs/31
benchmarks/14
.github/9
scripts/7

Docs found: AGENTS.mdLICENSE.mdREADME.mddocs/applications.mddocs/authentication.mddocs/background.mddocs/config.mddocs/contributing.mddocs/database.mddocs/endpoints.md

Package

pyproject.toml — starlette, 9 declared dependencies.

fullitsdangerous"jinja2"opentelemetry-api"python-multipart>=0.0.18"pyyaml"httpx>=0.27.0,<0.29.0"httpx2>=2.0.0"]

CI & config entrypoints

Structural health signals

Average score 7.6/10 across 49 analyzed source files; 6 hotspots surfaced.

These are deterministic review leads — size, churn, and structural signals — not proof of a bug in this project.

Recent history