Built-in support for something similar to nginx proxy_redirect default

[per-samuelsson]

Tried to read everything in both https://github.com/microsoft/reverse-proxy/issues/21 and https://github.com/microsoft/reverse-proxy/issues/13, plus related PRs, and did tests myself.

But I can't find anything like a built-in feature similar to that of nginx' proxy_redirect default (which is enabled there by default).

So, before I start implementing my own (using response transforms), just want to make sure I didn't miss anything? And, of course, also, if it's not there, I'd suggest it as a great improvement. 😃

Gist of what I'm looking for:

.AddTransforms(transformBuilderContext =>
{
    transformBuilderContext.AddResponseTransform(async transformContext =>
    {
        await transformContext.RedirectProxyLocationOfNewResource();
    });
})

where RedirectProxyLocationOfNewResource would implement something like

// => POST http://service.myproxy.com {...}
//   => POST https://some-backend-service.com {...}
//   <= HTTP 201: Location: https://some-backend-service.com/path/to/resource
// <= HTTP 201: Location: http://service.myproxy/path/to/resource

[per-samuelsson]

Oh, from what I read, I have understood the proposed solution would be to use X-forwarded and similar, and put this as a responsibility of the destination.

But that is out of scope for me, since the destination is external to me and not something I can affect (and clearly don't implement this scheme as of today).

[Tratcher]

Correct, this is not currently implemented. x-forwarded is the recommended mechanic but I understand that's not always viable. We recommend x-fowarded because Location is only one of many fields that may need fixing, and fields/links in the response body are a lot harder and less efficient to fix in the proxy.

[per-samuelsson]

Thanks @Tratcher for a fast and clear response. 👍 Feel free to close this issue as resolved. Keep up the good work.

Just a short comment on the answer:

We recommend x-fowarded because Location is only one of many fields that may need fixing

nginx have built-in support only for Location and Refresh response headers, which make sense to me. Any transform/URL rewrite for something else, you'd have to write yourself.

Built-in transformations of data in the body seem like a bad idea IMO, both from a performance perspective and even more, it would be really hard to get right. Better leave that to the audience.

[samsp-msft]

Triage: This is handleable with a custom response transform - we should look to add this example to the samples.

[SpringHgui]

is proxy_redirect has supported?