/openapi endpoint with forwarded header

[sknot-rh]

Signed-off-by: Stanislav Knot sknot@redhat.com

If I understood #432 correctly, this should fix it.

If we call /openapi endpoint and the x-Forwarded-Path header is set, its value is projected into basePath in the result openapi spec.

[ppatierno]

@elakito it would be great to have your feedback on this

[elakito]

Ok. It looks good but I have a few comments.

1. Regarding the header name, both x-forwarded-prefix and x-forwarded-path headers are used for this purpose and it seems x-forwarded-prefix is more widely used or mentioned (in google search, "x-forwarded-prefix" returns 6.920 hits whereas "x-forwarded-path" returns 793 hits). Therefore, it would be more convenient to look up both names so that it will work out-of-the-box in all environments.

2. for this path rewriting step, if this header is absent, would it be simpler to just return the original buffer than always doing json-parse-serialize to create another buffer?

3. another question regarding this path rewriting step, originally I thought one would use a templated original data with a template engine like mustache to set the variables. I think that would probably be more efficient than doing the json-parse-serialize approach but would create a new dependency to another lib or else would need some custom template variable replacing code. So, I am raising this point but no strong opinion about which approach is better.

4. for this rewriting to be useful, the host property should either be removed from openapiv2.json so that the client can simply assume the host to be the current target host or be replaced to the correct host using x-forwarded-host. I think simply removing this host property from openapi spec is a better choice than adding the host replacing code.

[elakito]

LGTM.
thanks.

[scholzj]

@sknot-rh Could you please have a look at the conflict? @ppatierno Could you please review this?