danger_accept_invalid_certs(true) is ignored when browser impersonation is enabled

[ehfkwlfkwl]

ClientBuilder::danger_accept_invalid_certs(true) does not appear to work when .impersonate(...) is enabled.

The same option is expected to disable certificate validation, but in the impersonation path primp builds a custom rustls::ClientConfig and passes it to reqwest via use_preconfigured_tls(...). Because of that, the reqwest builder's danger_accept_invalid_certs(true) setting is not applied to the preconfigured TLS config.

In the impersonation build path, apply_impersonation(...) creates a custom rustls::ClientConfig:

let tls_config = build_impersonate_tls_config(&settings, custom_certs)?;
let builder = builder.use_preconfigured_tls(tls_config);

At this point, the danger_accept_invalid_certs(true) setting from the underlying reqwest builder is no longer applied, because the TLS verifier has already been selected inside the preconfigured rustls config.

Possible fix:
Track the accept_invalid_certs setting in primp::ClientBuilder and pass it into build_impersonate_tls_config(...). When enabled, build the rustls config with a custom verifier, similar to reqwest's NoVerifier path:

let config = if accept_invalid_certs {
    builder
        .dangerous()
        .with_custom_certificate_verifier(Arc::new(NoVerifier))
        .with_no_client_auth()
} else {
    builder
        .with_root_certificates(root_store)
        .with_no_client_auth()
};

[ehfkwlfkwl]

I think this is part of a broader issue in the impersonation build path.

apply_impersonation(...) rebuilds/overlays several settings at build() time, after the normal ClientBuilder options have already been configured. This can make some builder options appear to be accepted but not actually honored when impersonation is enabled.

For example, default headers are applied like this:

let builder = builder.default_headers(settings.headers);

Since default_headers() inserts into the builder's header map, browser impersonation headers are applied after user-provided default headers and overwrite any colliding names. So a user doing something like:

Client::builder()
    .default_headers(headers_with_custom_user_agent)
    .impersonate(...)

may still end up with the impersonated browser's User-Agent instead of the explicitly configured one. The call order does not really help, because impersonation is applied later during build().

I also found a related protocol-selection issue with preconfigured rustls. In the impersonation path, primp builds a custom rustls::ClientConfig and passes it through use_preconfigured_tls(...). That config hardcodes:

config.alpn_protocols = vec!["h2".into(), "http/1.1".into()];

As a result, ClientBuilder::http1_only() only updates reqwest's HttpVersionPref, but it does not update the already-built preconfigured rustls ALPN list. The client can still advertise h2 in the TLS ClientHello even though http1_only() was requested.

So this is not limited to danger_accept_invalid_certs(true). The impersonation path needs to explicitly propagate relevant builder settings into the generated impersonation TLS config and header config, or apply impersonation defaults in a way that does not silently override user-specified options.