Skip to main content

effective_headers

Function effective_headers 

Source
pub fn effective_headers(
    configured: &BTreeMap<String, String>,
) -> BTreeMap<String, String>
Expand description

The headers a provider will actually send: drep’s defaults, then the configured table over the top.

The single statement of that precedence, for the reason crate::auth keeps one statement of the credential order: the request path, LlmClient’s Debug and drep doctor all have to answer the same question about the same entry, and when the default was applied inside the request instead, they answered differently. A config naming one header printed one and sent two, and a config naming none printed an empty set and sent a User-Agent. The operator debugging a gateway 403 is asking doctor exactly that question, and the case where it was silent was the case where they had not set one.

Case-insensitive, because HTTP header names are: a configured user-agent replaces the default rather than joining it, which is what the SDK’s own HeaderMap would do at send time anyway. Default-against-configured is the only collision this function has to settle - validate has already refused a pair of configured spellings, because there the two names are equally the user’s and picking one is not the caller’s to do.