Request's content-length inconsisent depending on features

[bryanburgers]

Whether the client sends a content-length header depends on what features are enabled.

Should this be inconsistent? Is this even something reqwest can control or is at the level of the tls libraries?

Given the code:

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let client = reqwest::Client::new();
    client
        .post("https://en4ai3fohs7sk.x.pipedream.net")
        .query(&[("feature", "rustls-tls")])
        //.query(&[("feature", "native-tls-vendored")])
        .send()
        .await?;
    Ok(())
}

with dependencies

tokio = { version = "1.32.0", features = ["rt-multi-thread", "macros"] }
reqwest = { version = "=0.11.20", default-features = false, features = [
    "json",
    "gzip",
    "rustls-tls",
    # "native-tls-vendored"
] }

When this is run with rustls-tls, the request headers include content-length: 0, but when run with native-tls-vendored the request headers do not include a content-length header.

When the request is made to http://... without any tls features enabled, the request headers do not include a content-length header either.

I have no idea if this requestbin is permanent or not, but you can see my tests here: https://public.requestbin.com/r/en4ai3fohs7sk.

Related: #1873