Support unencoded reserved characters in path segments
See original GitHub issueSome time ago, we had support for MatrixVariables added to Spring Cloud OpenFeign, using this processor.
This implementation works ok while sending requests to Spring REST controllers that can handle incorrectly encoded ; and = characters for matrix variables. However, an issue has been reported here that causes problems for servers that will not handle incorrect encoding of matrix variable reserved characters.
Basically, since matrix variables can appear in any path segment, they are handled by us as path params, with values stored in indexToExpander and get fully pct-encoded by feign-core, including their special characters, so we get /server/matrixParams%3Baccount%3Da%3Bname%3D instead of /server/matrixParams;account=a;name=n.
It looks like an issue that can only be addressed within feign-core and not as part of our integration. I could work on a fix if that’s fine with you. An idea that comes to mind is to introduce some kind of markers, say {{}} that would surround characters that should not be encoded within expanded path param chunks, but I’m also open to work on any other solution that the team might prefer. Let me know what you think about it.
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (4 by maintainers)

Top Related StackOverflow Question
@OlgaMaciaszek @oliverlockwood I’ve added #1537 to enable support for Path Style parameters. Expressions that start with semi-colons
;are treated as path style, a.k.a matrix style parameters.Examples
You no longer need a custom expander for this type of expression, as this change exposes
PathStyleExpressionas anExpanderfor use.For example, in
MatrixVariableParameterProcessor:If this meets your needs, please let me know and we’ll work on getting it released.
All, thank you for your patience. I understand the issue and it’s importance to you all. The root of the issue is that our URI template expression handling is very simple and limited. I have an idea where we can move expansion of custom expanders deeper into the parsing. This would require expanders to manage pct-encoding directly however, which may break existing integrations.
I’d like more time to think it through.