Warp 0.4

Apply the Rust 1.98 baseline first. These rules target Warp 0.4 filters and replies with Tokio 1 and Hyper 1 / http 1 integrations, and were checked against 0.4.3. Apply the baseline's compiler, data-access, outbound-network, and secret-handling controls to application dependencies.

Runtime and feature boundaries

• Enable server explicitly for warp::serve; enable multipart, websocket, and response-compression features only when used. Keep test in development dependencies. Warp 0.4.3 has no default features and no supported tls feature; do not copy server or TLS APIs from 0.3 examples.
• Check hyper, hyper-util, and h2 in Cargo.lock as well as Warp itself: Cargo resolves them under their own semver ranges, so a current Warp can sit on an old h2. Find each resolved copy with cargo tree -i h2 and raise it with cargo update -p h2. Warp's server answers HTTP/2 as well as HTTP/1 through Hyper's automatic protocol detection, so h2 matters even without TLS.

Routing and authorization

• Pair endpoint paths with explicit method filters such as warp::get() or warp::post(). End exact routes with warp::path::end(); warp::path!(...) supplies this unless its / .. prefix form is used. warp::path("name") alone also matches longer paths.
• Put path and method selection before credential extraction and body parsing. Consume the body only once in the selected route, and defer state changes until all checks pass: .or() restores path matching when trying an alternative, but does not restore a consumed body or undo effects.
• Protect every