Idea/Suggestion: GraphiQL idiomatic & improved reverse proxy detection.

[MaxLithia]

PR #1220 technically introduced a minor regression in that it removed a relative path "." from the GraphiQL index.html. It seems that path was added so that the base-path the browser is on would be respected when calling the main /graphql endpoint.

I ran into this today when trying to make GraphiQL work nicely for my team behind a reverse proxy that does some HTTP path rewriting.

Previously, for similar reasons but for a different tool built with Spring+Thymeleaf, I went through pains to make sure X-Forwarded headers are respected via the the builtin Spring ForwardHeadersStrategy which can be trivially enabled with sane defaults with this property: server.forward-headers-strategy: framework

Spring Web, in ways I haven't fully investigated, will then use these pieces whenever a url needs to be rendered. This wires into Thymeleaf nicely and for free, and lets you write thymeleaf-idiomatic things like this:
<form method="post" th:action="@{/blah/foo}" ... and Spring+ thymeleaf will always respect the X-Forwarded-Prefix header that my reverse proxy infra makes sure to set.

Returning to the point of this discussion, the com.netflix.graphql.dgs:graphsl-dgs-spring-webmvc-autoconfigure dependency will only consider the origin (hostname, basically) and the configured graphql API path. This breaks the reverse proxy situation. dgs.graphql.path SHOULD be /graphql so that http://localhost:8080/graphql continues to work as normal, as the e2e networking is set up to do so. The expectation, more-or-less, in the current GraphiQL autoconfiguration is that the browser should be working off the same exact path (http://localhost:8080/graphql), which is obviously is not the case with reverse proxies.

With this discussion topic I'm hoping to evaluate if the DGS GraphiQL autoconfigure code could either set up a similar url rewriter to play nice with reverse proxies via the same idiomatic spring pieces mentioned above... OR have a separate graphiql api path configuration (that is by default the same as dgs.graphql.path that can be set independently for people in my situation. Maybe something likedgs.graphql.api-path).

With whatever sounds good here for folks I'd be happy to take a crack at creating an issue on the better-sounding path and also open up a PR.

[kailyak]

Hi @MaxLithia, thanks for bringing this up.
So, previously, because the relative path was used, it would play nicely in situations where path info outside of what's encompassed by origin are needed, which seems to be what you encountered with the situation of a reverse proxy being used for path rewriting involving the graphiql URL.

This does seem like something we would want to bring back in and would accept a PR for.
For the approach, Thymeleaf does seem to bring greater flexibility, like being able to use header info but the scope here seems more constrained to bring it in as a dependency. That is my thoughts though with limited context of Thymeleaf.
cc: @srinivasankavitha any thoughts here?

[MaxLithia]

Sorry I wasn't more clear: I don't think we should use Thymeleaf, but we could perhaps find a clean way to use the ForwardHeadersStrategy that is already a part of spring web autoconfigure (this is what Thymeleaf does).