Add request event hook

There was a scenario where I need to intercept the request and was searching for if there is some way can that be done, then I found the event hook but only `response` event hook is supported.
I hope adding `request` hook can be useful, if yes I would like to implement that.


Any pointers or suggestion appreciated.

Thanks


Can you tell what exactly you mean by request hook ? What does intercepting a request mean ? It sounds like you want to do something after request has been made - for which you can use response hook

I need the same thing. A hook that retrieves the `Request` or `PreparedRequest` object in the moment when it is sent (without waiting for the response).

I implemented the hook in PR #5044.

What a bummer that PR #5044 was closed..   I'd love to have the request hook as well.
My scenario is that for some tests I need to manipulate the headers right before the request (after business logic is done in the REST client).

@joaonc is there a reason you can’t use the PreparedRequests workflow for this use case?

I guess there are several ways to skin this cat.  I have a business layer where the REST clients to our web services are defined (ex `AccountService` has a `get_account(account_id)` method) and those clients handle urls for different environments, logging, headers (we have some headers that require business logic), etc.

In some of my tests, I wanted to alter these headers.
One easy way to do it would be to add `request` to the list of hooks.
Another is to have these REST clients accept `headers` as a parameter.

I have a base REST client from which all others derive and ended up adding a check for `hooks.get('request')` and go from there, basically adding the functionality myself.  If it gets added to the `requests` library later, should be easy to switch.

So there seem to be a couple use-cases here that I wanted to summarize and directly address:

1. A REST client library that needs to conditionally perform some logic
2. Someone wanting to handle redirects in a bespoke and unexplained way

As someone who has written multiple REST client libraries, there are many ways to skin this cat and it all depends on how well designed the client library is. For anything that's going to be remotely complex or long-lived, I personally like a layered approach. By which I mean:

- The bottom layer is a class that wraps/extends a `requests.Session` (ideally, it doesn't subclass so that you could swap it out for something similar in the future if you wanted and the rest of your library wouldn't have to know)
- The next layer is what understands URL building and other business logic that might need to happen. This could be used by power users who want to just see response data directly
- The final layer parses the prior layer into friendly objects.

This layering is not different from how you might think about a database library (bottom layer is roughly equivalent to a database specific driver, then the abstraction that parses and returns tuples from the driver, then the ORM). It's quite nice for testing purposes and it allows you to split up business logic into appropriate places. At the bottom layer, you can use the prepared request workflow that Nate mentioned above to prepare a request with your session and then apply your overrides.

For handling redirects in a bespoke way, there's already a hook for that. In fact, this very library itself uses [that hook for that purpose](https://github.com/psf/requests/blob/aae78010e987a414c176bddbf474cd554505219c/requests/auth.py#L278-L296). Unfortunately, the hooks in that code are relying on undocumented features that aren't something I want others to do. As an alternative to that, we have much of the redirect logic in a separate class that gets mixed into the Session. Following the APIs in that class, one could sub-class and extend that mixin and then create their own redirect-handling session: `class Session(requests.Session, MyRedirectMixin)`. It's not ideal, but it works and the APIs there are possible to understand.

I'd like to get a breaking release out that gives more flexibility around the latter case specifically, but I think I'd also like a different way for hooks to work - namely I feel like hooks should have a way to return a new `PreparedRequest` that is used as a next request. I don't want hooks to be making additional requests that then hide themselves from the user (the way HTTPDigestAuth works currently) but that's a big breaking change