requests: Allow controlling whether propagation headers are sent

Problem

We’d like to use opentelemetry to instrument requests for internal HTTP requests, but we also send requests to external parties. If we put user IDs in baggage, we’d prefer not to send those outside of our systems, but there is no way to do that with the current approach.

Desired solution

Provide configuration for which origins have propagation enabled. This could take the form of allow- and deny-lists, or a user-provided callback that returns a boolean based on the request.

Alternatives

Let the user instrument individual Session objects so that they can use an instrumented Session for internal calls, and an uninstrumented one for external calls. The API could be mirrored off of the flask instrumentation, which provides an instrument_app method.

So, perhaps an interface like:

class RequestsInstrumentor(BaseInstrumentor):

    # ... existing contents

    def instrument_session(session: requests.Session) -> None:
        ...

    def uninstrument_session(session: requests.Session) -> None:
        ...

This has a downside of not creating spans for those calls, when all we actually want is to prevent context propagation. It also forces cookie saving and connection pooling on users, making it hard to get the same behaviour as the bare requests.{get, post, ...} methods.

[owais]

I think custom propagator is actually a pretty good solution for this use case. I don’t think we need to address this in stock propagators or SDKs since it is very easy to implement in each project. Someone could even publish a opentelemetry-baggae-with-privacy-respecting-feature-and-other-goodness to pypi for others to use 😄

As long as this project makes it possible for the community to build reliable solutions to such problems, I don’t think we need to address them here.

Closing this but feel free to re-open if anyone thinks this is not viable for all cases.

[owais]

I do like the idea of something supported within the libraries themselves. The suppress_instrumentation thing looks like an internal detail though, and not something a library consumer should use. Is that right?

Right, it’s meant to be used only by the SDK and instrumentations.