Chris Ross

The shape of these internal types may change due to https://github.com/microsoft/reverse-proxy/issues/1980.

Similar: https://github.com/microsoft/reverse-proxy/issues/193

We prefer to keep issues opened by costumers to track demand. The cross-reference should be adequate, or we can add those details to this issue.

It's doable in theory. A few things to be careful about: A) Be very careful mirroring the request body. We stream the request body today (if any), and streaming that...

Load balancing shouldn't be a problem. I'd expect the mirror target to be a separate backend group rather than a specific endpoint instance, and load balancing is per group.

As for the modifications and such its just a matter of caution. We need similar caution for other reasons such as if we had a retry-on-failure feature.

We received out of band feedback requesting mirroring support specifically for IHttpProxy. Most of the [above](https://github.com/microsoft/reverse-proxy/issues/105#issuecomment-619473936) concerns apply, but there are fewer components to contend with.

> Currently I set up a second HttpMessageInvoker and just copy everything I need onto that @Towmeykaw can you show a rough outline of your code for that? And where...

@Towmeykaw - There are still some possible side-effects there. - Chunked responses aren't completed until the pipeline unwinds or you call httpContext.Response.CompleAsync(). The client may end up waiting for the...

That should be `{**path}` to match more than one segment.