dart-lang/http: a monorepo where the Client class is the seam, not the library

A mono-repo of packages, not a single library

The repository is the dart-lang/http organisation's home for a family of packages, and the first thing to understand is that the root README is an index rather than a manual. The project documentation is one line: package:http contains a set of high-level functions and classes that make it easy to consume HTTP resources, it is multi-platform, and it supports mobile, desktop and the browser.

Underneath that, the repository carries a package table with a dozen entries, each with its own version and its own release cadence. The layout is a `pkgs/` directory with one directory per package, and a `mono_repo.yaml` at the root that is what makes that arrangement work. There is also a `tool/` directory, an `analysis_options.yaml` for the lint rules, and a `CONTRIBUTING.md` that covers contributing to any of the packages.

The consequence for a user is that `package:http` and `package:http2` are separate publications with separate version numbers. The release history shows them moving independently: http2 reached v3.1.0 on 2026-09-18, http is at v1.5.0 from 2025-08-07, and web_socket_channel is at v3.0.3 from 2025-04-17. Nothing in the repository forces those to move together, so an application that depends on several of them is choosing its own compatibility policy.

The licence is BSD-3-Clause, with the licence text at the repository root.

The Client class is the seam the whole design hangs on

The architectural centre of the project is the `Client` class, and understanding it explains both the plugin packages and the test packages.

The `Client` is an interface: something that can send a request and return a response. package:http supplies an implementation, but the design assumes you may want a different one. The Flutter plugins in the table are exactly that. `cronet_http` is an Android Flutter plugin that provides access to the Cronet HTTP client. `ok_http` is an Android Flutter plugin that provides access to the OkHttp HTTP client. `cupertino_http` is a macOS and iOS Flutter plugin that provides access to the Foundation URL Loading System. Each of them replaces the transport underneath the same `Client` interface, so the code that makes requests does not change.

That is a real difference in approach, not a wrapper. Each of these plugins sits on an existing platform HTTP client, so an application using those plugins inherits the platform's connection pooling, cache and proxy behaviour rather than a Dart implementation of it. The cost is that the platform's behaviour is not always the behaviour the Dart implementation would have given you, and the differences show up in redirects, headers and error handling.

The `http_profile` package exists for a related reason: it is a library used by HTTP client authors to integrate with the DevTools Network View, so a custom `Client` can show its traffic in the debugger.

Conformance test packages keep third party clients honest

Two packages in the table exist purely to test other people's code, and they are a good indicator of how seriously the project takes the `Client` contract.

`http_client_conformance_tests` is described as a library that tests whether implementations of package:http's `Client` class behave as expected. `web_socket_conformance_tests` does the same for implementations of the `WebSocket` class in `package:web_socket`. These are not test suites for the packages in the repository. They are a specification expressed as executable code, which a third party can run against their own `Client` implementation to check that it behaves the way the ecosystem expects.

The benefit is that the contract stops being folklore. A team writing a `Client` on top of a different HTTP stack, a proxy, or a mock for tests has something to run. The same applies to a team maintaining an internal wrapper around `package:http` who want to be sure their wrapper does not change semantics.

The `flutter_http_example` package plays a similar supporting role, demonstrating how to use package:http in a Flutter app, and it is listed without a version, which is the convention in the table for a package that is not published.

Together, the plugins and the conformance packages make the family bigger than a single library would be, and they make the family usable by people who are not writing the core.

The supporting cast: parsing, HTTP/2, WebSockets and a server

Around `package:http` sit the packages that handle the adjacent protocol work.

`http_parser` is a platform-independent package for parsing and serializing HTTP formats, which is the layer you would reach for when you need to read or write a message format without making a request. `http2` is an HTTP/2 implementation in Dart, and it is the most actively released package in the family, with v3.1.0 dated 2026-09-18.

For WebSockets there are three related packages. `web_socket` is an easy-to-use library for communicating with WebSockets that has multiple implementations, `web_socket_channel` is a WebSocket API that enables cross-platform communication via StreamChannel, and `web_socket_conformance_tests` tests whether implementations of the `WebSocket` class behave as expected. The channel package is the one most applications touch, because a StreamChannel is the shape the Dart streams ecosystem expects.

There is also `http_multi_server`, a dart:io HttpServer wrapper that handles requests from multiple servers, which is the one entry in the table that points at serving rather than consuming. That matters for framing: the repository as a whole is not only a client, but `package:http` itself is a client API, and the server side of the story lives in the wrapper and in dart:io.

Where the documentation stops, and where the project is the wrong fit

The honest limitation here is that the root README is short by design. It lists the packages and points to pub.dev for each one. There is no architecture document in the repository, no migration guide for the `Client` interface, and no description of what the platform plugins change relative to the default implementation. Per package documentation lives on the pub.dev package pages, linked from the table.

That has a practical consequence. When you swap the transport, the behaviour differences are in the plugin's own documentation, and the difference between Cronet, OkHttp and the Apple URL loading system is a per-platform question rather than one this repository answers.

The scope is the second limitation. package:http is an HTTP request API. It is not an application framework, and the repository does not describe caching policies, retry behaviour, cookie handling or an interceptor pipeline, because those are not what it is for. If your requirement is a full featured data layer with caching, retries and logging baked in, this repository is a layer rather than the whole thing, and you will be composing it with something else.

There is a third, more specific point about the plugins. Because `cronet_http`, `ok_http` and `cupertino_http` are Flutter plugins, they only apply inside a Flutter application. A plain Dart command line or server program cannot use them, and it does not need to, because on the server `dart:io` provides its own HTTP client and there is no platform web stack to defer to. That is the same reasoning that makes the ecosystem work, and also the reason the plugin set is deliberately narrow.

BSD-3-Clause terms and a repository that versions each package on its own

The licence is BSD-3-Clause, with the text in the `LICENSE` file at the repository root, which covers every package in the family. For a package that will be a dependency in almost every Dart application that talks to a network, a permissive three clause licence is the least interesting thing about it, and that is the point: there is no licensing decision to make.

The maintenance picture is worth reading carefully, because the packages do not share a rhythm. The most recent release in the family is http2 v3.1.0 on 2026-09-18, followed by http v1.5.0 in August 2025 and web_socket_channel v3.0.3 in April 2025. The last push to the repository was on 2026-10-14. So the source is being worked on across the family, while individual packages sit at whatever version their own changes justify.

That is the normal arrangement for a mono-repo with independent versioning, and `mono_repo.yaml` is the file that encodes it. It does mean that a project depending on both `package:http` and `package:http2` is maintaining a dependency graph with independent moving parts, and that a security advisory against one package does not necessarily bump the others.

Contributions are coordinated through a single `CONTRIBUTING.md` covering all the packages, and the presence of a `tool/` directory alongside the per package directories is what keeps the automation for publishing and versioning in one place rather than scattered across a dozen separate repositories.

Editorial conclusion

dart-lang/http fits a Dart or Flutter project that needs one HTTP API across mobile, desktop and browser, and it fits a team that wants to swap the underlying transport for Cronet, OkHttp or the Apple URL loading system without changing call sites. It does not fit a project that needs a server framework or a caching layer, since the repository's client-side scope stops at the request API. Before you adopt the plugin packages, check that the `Client` implementation you swap in passes `http_client_conformance_tests`, and note that the packages version independently, with http2 at 3.1.0 and http at 1.5.0, so pinning them together is your job.

Frequently asked questions

Official sources

1. dart-lang/http on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases