Expose the default headers used by clients

[er-vin]

This is convenient in debug and testing scenario for code using reqwest. In particular for introspecting to know what will be sent without introducing a MITM.

[er-vin]

@seanmonstar One failure with the MSRV check, it looks related to the 0.1.16 update of hyper-util. Paths forward:

• bumping rust-version to 1.70 or later
• pin hyper-util to 0.1.15

Any preference? Want me to address it in this PR or a separate one?

[seanmonstar]

Thanks for the PR! I'm curious, you mentioned for debugging and inspecting. Is there a significant benefit to having programmatic access vs just including them in the fmt::Debug output of the Client?

[er-vin]

Thanks for the PR! I'm curious, you mentioned for debugging and inspecting. Is there a significant benefit to having programmatic access vs just including them in the fmt::Debug output of the Client?

Yeah, my comment was maybe a bit misleading. It's really for the testing part that it comes in handy. In particular if you want to integrate with vcr cassettes. You can't put in them all the headers which will be used in practice if you can't know the ones in the client.

[er-vin]

Looks like it can be merged now.

@seanmonstar once this is merged, any idea on when there will be a release containing this patch? I'm unsure about the release cycle used for this project.

[er-vin]

@seanmonstar Since I noticed other PRs getting in, I've rebased this one to keep it ready. Do you have any concerns left with it?

[seanmonstar]

It's really for the testing part that it comes in handy. In particular if you want to integrate with vcr cassettes. You can't put in them all the headers which will be used in practice if you can't know the ones in the client.

Hm, I feel like I don't quite understand. Can you say more?

My hesitation is around taking caution when exposing references, since those expose internal details (you can't factor away to something else, since you can't produce a reference only within a function).

[er-vin]

It's really for the testing part that it comes in handy. In particular if you want to integrate with vcr cassettes. You can't put in them all the headers which will be used in practice if you can't know the ones in the client.

Hm, I feel like I don't quite understand. Can you say more?

Sure, let me expand. I'm having integration tests which serialize requests sent in the VCS cassette format (using vcr_cassette). This is done by taking the built Request and calling (among other things) headers() on it.

Now some of the headers are supposed to be used by all the requests, so it would make sense to move then in the default headers of the client. In my test, I can get access to the client and the request, but the request doesn't carry the default headers of the client. So my tests become "blind" to any header moved from requests to client.

That's why I'd like my tests to be able to get access to the client's headers to have a complete view again.

An alternative would be for the Request to provide all the headers, but if I understand correctly it wasn't the case when default_headers() was introduced on the ClientBuilder and that was on purpose. Also, changing this now means a behavior change which might not be desirable.

My hesitation is around taking caution when exposing references, since those expose internal details (you can't factor away to something else, since you can't produce a reference only within a function).

Note that I went with references because that's what headers() was already exposing on Request. But I admit I was hesitant to switch to value instead. If you prefer I could do this.

[er-vin]

@seanmonstar Did my previous comment help make things clearer?

If not feel free to ask questions and I'll expand.

[er-vin]

@seanmonstar Looks like I missed the boat for the latest release. Any chance to attract your attention again and see what to do with this patch? Thanks in advance.