Current architecture mainly works like this now:

• Outer layer(ctx, reqeuest) -> Response
• Inner layer(ctx, reqeuest) -> (Ctx, Response...)
• Deeper inner layer(ctx, reqeuest) -> (Ctx, Response...)

This makes it possible for each inner layer/svc to modify ctx, or use an internal ctx for some layers and return an updated ctx to the outside service. This way multiple services can work together while achieving isolation at the same time. This however has one huge drawback, information available in ctx is dropped at the outer service and as such is not available to the outside caller.

One example of where this is currently a pain point: Making a request with an HttpClient and trying to access the server certificate chain stored in the NegotiatedTlsParameters.

Some solutions that were discussed in private already and will not be implemented:

1. Always return ctx, even in outside layers. Will not be used as this makes the return type of outer services complicated and weird
2. Inject ctx in response.extensions. Creative workaround but is kind of a nasty solution, and only works if outer layer is an http client

This issue is here to discuss potential solutions and once a rough solution is ready work for it can be started in a PR.

Some potential solutions:

1. Extend all services that drop ctx with an extra parameter beforeDropCallback |ctx: Ctx, response: Response| -> Response. This way external users can use this callback to move data out of ctx and into the response or into some external storage.

2. Split all services that drop ctx into two services.
   The outer service is very simple and only does this and can be generic over response

ctx, response = self.innner(ctx, request).await;
response

The inner service is basically what the service is right now, without the dropping ctx part. By default when using a service like this it would be constructed with both layers immediately after each other. But if needed they could be split into separate layers which would make it easy to design one or multiple layers/services in between them to extract data. This solution is a bit more flexible then the first one, but does require more work

3. Something completely else