Builders don't have a fn to set the header map when the user already has a HeaderMap value.

[carllerche]

Currently, the only builder fns are for inserting header entries, but if you just want to set the header map, there is no API for that.

[carllerche]

It is currently possible to set the HeaderMap after building:

let mut request = Request::builder()
    .method("get")
    .body(());

*request.headers_mut() = my_headers;

This isn't super ergonomic or discoverable.

This issue is flagged as 0.1 as it might require breaking changes if Builder::headers is renamed.

[alexcrichton]

We could change headers?

[carllerche]

We could... the extend behavior also seems useful to have as well, but I couldn't think of a great name.

[alexcrichton]

Maybe something like headers_reset?

[carllerche]

I guess replace_headers could work... It is unfortunate that all the other setters explicitly set the value except the one for HeaderMap.

The other option would be to rename the current headers fn -> insert_headers.

Also, a thought occurs to me. Currently, headers takes an into iterator of (K, V) which has the possibility of having duplicate keys. HeaderMap has two ways to handle duplicate keys (replace or append). Maybe having insert_headers and append_headers on the builder isn't too terrible?

[seanmonstar]

Something that occurs to me is it doesn't sound like anyone is super convinced by any of the names. It's easy to add in methods later, but hard to fix these after they are added.

[carllerche]

@seanmonstar I'm totally fine punting on adding fns. The real question here is what to do about the headers fn that is currently part of the builder.

Maybe we should just yank it for 0.1 and defer figuring out what that fn should do.

[seanmonstar]

If we aren't certain that headers should extend (append), then seems prudent to remove it for now. 👍

[carllerche]

After removing the headers fn, this issue can be fixed post 0.1.