feat: add http-backend feature for slimmer http builds - #1078
Conversation
GlenDC
left a comment
GlenDC
left a comment
There was a problem hiding this comment.
You are correct and you are going in the right direction. However I would not focus so much on client here. Your problem can be made more generic.
What about if we introduce a feature named http-backend which enables dep:rama-http-core and dep:rama-http-backend. And drop the http-client feature introduced by you. http-backend would also enable http and http-full would enable http-backend. http-backend would also enable dep:tokio.
For the EasyHttpClient I would feature-gate than on http-backend, dns and tcp.
I think that makes more sense than specifically focussing on client. As in general I want to keep the amount of features as little as possible. And by doing it like I propose we can also use the same gating for proxy and server stuff without having to also add features for those. Should we have the need for it in future.
|
What i did here is introduce This was a quick hack and i was not sure if that align with your vision of the project. Your solution is better, and i will think more tomorrow about the edge cases before updating this PR. |
The EasyHttpWebClient and its connector builder were only reachable via http-full, which drags in ws, idna (icu), compression, embedded ua profiles, multipart, html and rss. None of those are required by the client stack itself. Introduce http-client with the minimal closure the client needs: http, tcp, dns, rama-http-backend, rama-http-core and tokio. Gate the http::client module and the rama_http_core re-export on it. http-full is now a strict superset (http-client plus the extras), so existing users are unaffected. A client-only build drops 47 crates from the dependency tree (254 to 207). Optional features such as compression, rustls, ring, socks5, opentelemetry and unix compose with http-client as before.
Per review: rather than a client-specific feature, introduce the generic http-backend closure (dep:rama-http-backend, dep:rama-http-core, dep:tokio) so proxy/server code can reuse the same gating later without adding more features for those. EasyHttpWebClient (http::client) still additionally needs dns + tcp, so it is gated on http-backend + dns + tcp. http-full now enables http-backend directly and re-adds tcp + dns itself, keeping it a strict superset so existing http-full consumers of EasyHttpWebClient are unaffected.
3d2429f to
ad4b64d
Compare
GlenDC
changed the title
2 participants
The
EasyHttpWebClientstack was only reachable viahttp-full, which drags in ws, idna (icu), compression, embedded ua profiles, multipart, html and rss — none of which are required by the http backend itself.The new
http-backendfeature enables justdep:rama-http-backend,dep:rama-http-coreanddep:tokioon top ofhttp.http::clientis gated onhttp-backend+dns+tcp, andhttp::tls(CertIssuerHttpClient) now shares those gates, fixing a pre-existinghttp,tlsbuild break.http-fullstays a strict superset (its redundantdep:ahash, already enabled viastd, is dropped), so existing users are unaffected.A client-only build (
http-backend,dns,tcp) drops ~50 crates from the dependency tree (229 → 176 without default features). Optional features such as compression, rustls, ring, socks5, opentelemetry and unix compose with it as before.