Design an internal per-request config system

[seanmonstar]

The client builder provides a lot of configuration options. It's really convenient to be able to configure once and have all requests use that. But it's also very very common for users to ask to be able to customize one of the options just for a single request. It feels wasteful that the current solution is to create a separate Client, since they're not free.

Some of those feature requests:

• feat: Per-request redirect policy override #2440
• Allow DNS overrides per request #2347
• What should I do if I want to set different proxy url for every request? #1842
• Disable timeout at the request level #2639
• Allow setting no_gzip / gzip for Request #2616

Instead of adding support ad-hoc (well, we already did add one option, but before it gets worse), I'd like to come up with an easy internal system to support all sorts of config. I suspect the best way would be to store options in the request extensions, and then change the pattern of access self.client.config.blah to something like ReadTimeout::get(&req, &client), which will know to look in the request extensions first, and then look on the client if it isn't set.

To start off:

• Add an http::Extensions field to Request.
• Change Request to store the optional timeout in the extensions.
• Design a system or pattern or trait or something (internally facing) so that we always look in the request before checking the client config, to reduce accidentally forgetting to check the request.

[Xuanwo]

Hi @seanmonstar, thanks so much for kicking this off—I'm really interested in this work.

Just one quick question: Will we be using a struct called RequestConfig, or are we thinking of a collection of individual items like ReadTimeout?

[seanmonstar]

Probably individual types. At least that's my gut feeling. What do you think?

[Xuanwo]

Probably individual types. At least that's my gut feeling. What do you think?

If we use individual types, we’ll need to introduce several configuration-related types and an additional trait. On the other hand, opting for a single struct increases the memory footprint for every request.

But it's entirely an internal implementation detail, so we can change it at any time. It seems easier to start with just ONE struct to see how it works and then decide whether to split it into separate types for each config style.