ControllerLinkBuilder and multiple X-Forwarded-* headers values. (issue #509) #519
Conversation
|
Would also supersede #466. |
|
Is there a way we can use |
|
I can give it a try. So you're saying we should care about X-Forwarded-Ssl, even if UriComponentsBuilder doesn't? Isn't it more appropriate to file an issue upstream? |
|
I am about to file one right away, I just assume a bit of a longer cycle and am not sure it's gonna be introduced in 4.3 in the first place. |
|
Alright, so we'll implement X-Forwarded-Ssl as a work-around for the meantime. |
|
I did a bit of research and can't really find a place where the intended behavior is really well defined. I guess I'll refrain from asking that to be added in Spring Framework then and rather just keep our current implementation around (i.e. the workaround) as we should be able to move quicker or even remove that support easier than core Spring Framework can. |
| if (hasText(proto)) { | ||
| builder.scheme(proto); | ||
| } else if (hasText(forwardedSsl) && forwardedSsl.equalsIgnoreCase("on")) { | ||
| UriComponentsBuilder builder = UriComponentsBuilder.fromHttpRequest(new ServletServerHttpRequest(request)); |
There was a problem hiding this comment.
Don't we slightly change the logic here? Previously, if a protocol header was defined in any way, the SSL setting was disregarded. I think we'd override it here, wouldn't we?
There was a problem hiding this comment.
This is correct. I'll add a test case that makes sure ambiguities are resolved in the same manner.
|
@olivergierke I think I'm done. On a side-note: ControllerLinkBuilder is one of five files using windows newlines... |
…Framework. Removed the custom handling of proxy headers in ControllerLinkBuilder in favor of the behavior of UriComponentsBuilder in Spring Framework. The only thing that we keep custom is the handling of X-Forwarded-Ssl as it's rather non-standard. Original pull request: #519.
Formatting and author note. Original pull request: #519.
|
That's polished and merged. I also added you to the team so that you should be able to push issue branches to the repo directly (i.e. |
Open for discussion: UriComponentsBuilder does not respect X-Forwarded-Ssl, and I didn't see any JIRA issue adding this support. So for now, it's a question if spring-hateoas should just be aligned with the feature set of spring-framework, or add its own customizations. This would basically revert the PR for issue #112. I would vote for aligning it with what UriComponentsBuilder supports, but I'm not to decide.
That's why I put a junit.Ignore on them until this is clarified.