Skip to content

ControllerLinkBuilder should be extensible #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
radarsh opened this issue Dec 19, 2012 · 4 comments
Closed

ControllerLinkBuilder should be extensible #33

radarsh opened this issue Dec 19, 2012 · 4 comments
Assignees
Milestone

Comments

@radarsh
Copy link

radarsh commented Dec 19, 2012

Current implementation of ControllerLinkBuilder relies on Spring's ServletUriComponentsBuilder to construct links. The problem with ServletUriComponentsBuilder is that it is poorly designed (uses only static method calls), eliminating the possibility to extend and enhance the behaviour.

One typical scenario that I discovered yesterday:

Our tomcat server is hosted behind Apache. The client (browser) accesses a URL using www.example.com/path/to/resource. However, because of the way Apache has been set up, it doesn't send along the Host header value of www.example.com to Tomcat. Instead, it sends the internal IP address. The original hostname of www.example.com is set in an X-Forwarded-Host header.

Now, because Spring's ServletUriComponentsBuilder uses request.getServerName() to construct the hostname part of the URL, any generated URLs will have the internal IP address instead of www.example.com.

The only way I can fix this currently is by either:

  • Creating a HttpServletRequestWrapper that takes the value of X-Forwarded-Host header and sets it to Host header.

OR

  • Rewriting ControllerLinkBuilder logic to not use Spring's ServletUriComponentsBuilder.
@odrotbohm
Copy link
Member

LinkBuilder interface is happily awaiting new implementations. :) To be honest, this seems to be something that should be filed against ServletUriComponentsBuilder in Spring framework as it seems to be a reasonable enhancement.

@rstoyanchev
Copy link

In terms of enhancing the behavior of ServletUriComponentsBuilder:

ServletUriComponentsBuilder builder = ServletUriComponentsBuilder.fromCurrentRequestUri();
String forwardedHost = request.getHeader("X-Forwarded-Host");
if (forwardedHost) {
    builder.host(fowardedHost);
}

I agree that filing a ticket in SPR JIRA is appropriate.

@radarsh
Copy link
Author

radarsh commented Dec 19, 2012

Thanks. I have just opened an issue on Spring JIRA.

odrotbohm added a commit that referenced this issue Dec 19, 2012
When setting up the builder we now set the host to the value held in the X-Forwarded-Host [0] header if present. This allows to render appropriate URIs in reverse proxy scenarios. This is essentially an extension of ServletUriComponentsBuilder that will be fixed in there eventually. See SPR-10110 [1] for details.

[0] http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10
[1] https://jira.springsource.org/browse/SPR-10110
@odrotbohm
Copy link
Member

Added a temporary fix to ControllerLinkBuilder until the issue is solved in Spring Framework.

@ghost ghost assigned odrotbohm Dec 19, 2012
dschulten pushed a commit to dschulten/spring-hateoas that referenced this issue Jan 27, 2013
…st header.

When setting up the builder we now set the host to the value held in the X-Forwarded-Host [0] header if present. This allows to render appropriate URIs in reverse proxy scenarios. This is essentially an extension of ServletUriComponentsBuilder that will be fixed in there eventually. See SPR-10110 [1] for details.

[0] http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10
[1] https://jira.springsource.org/browse/SPR-10110
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants