-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Truncated JSON header value with @Headers #1464
Comments
We've run into this as well (using the |
The annotation based |
This breaks our code. We're adding a custom JSON structure to a HEADER which now gets truncated. |
Same problem here with the |
Ran into this today after upgrading from an older version to 11.8 |
Any solution to this problem? |
any update? |
Blocked by the same problem. Any update or a workaround to resolve this please. |
Hi @suryamurali1991 looking for volunteers to help fixing this issue. |
@velo I've seen the PR was close, any chance the issue gonna be attended soon? |
@SikoraAdam it's still waiting for someone to make the necessary changes. I'm willing to review it and get the release out of the door. Feel free to take a look on the comments we left at the PR and make the necessary changes |
I confirm that we are also impacted by this issue. |
Same problem for us. To sidestep it temporarily we're pulling in feign-core 11.0
|
I ran a git bisect on this issue and narrowed it down to the following commit: f8ad8670e3dc73862f52eec475464a301e8c41cc That commit did some much needed work. No way to revert it. The issue is not in the HeaderTemplate expand function, nor is it in the Expression or Simple Expression code. As far as I can see the RequestTemplate appears to be expanding the header template more than once. Resulting in an expression being expanded to JSON and then the Json being treated as a template and the Expression expansion going off the rails there. I have a fork and commit with the duplication unit tests here: Working on a sensible fix. |
This change adds a new `appendHeader` internal method to `RequestTemplate` allowing for already resolved headers to be added to the resolved `RequestTemplate` preventing duplicate expression processing by using another new method `HeaderTemplate.literal` and `HeaderTemplate.appendLiteral` respectively. I chose this route as it isolates the change to be applied only after the original `HeaderTemplate` has been resolved. While it does expose new public `HeaderTemplate` APIs, I feel that is an OK trade off, allowing a new escape-hatch for situations where URI template processing is not acceptable for Header values.
This change adds a new `appendHeader` internal method to `RequestTemplate` allowing for already resolved headers to be added to the resolved `RequestTemplate` preventing duplicate expression processing by using another new method `HeaderTemplate.literal` and `HeaderTemplate.appendLiteral` respectively. I chose this route as it isolates the change to be applied only after the original `HeaderTemplate` has been resolved. While it does expose new public `HeaderTemplate` APIs, I feel that is an OK trade off, allowing a new escape-hatch for situations where URI template processing is not acceptable for Header values.
Could you please let me know if this fix has been released? |
|
Thank you. |
This change adds a new `appendHeader` internal method to `RequestTemplate` allowing for already resolved headers to be added to the resolved `RequestTemplate` preventing duplicate expression processing by using another new method `HeaderTemplate.literal` and `HeaderTemplate.appendLiteral` respectively. I chose this route as it isolates the change to be applied only after the original `HeaderTemplate` has been resolved. While it does expose new public `HeaderTemplate` APIs, I feel that is an OK trade off, allowing a new escape-hatch for situations where URI template processing is not acceptable for Header values.
This change adds a new `appendHeader` internal method to `RequestTemplate` allowing for already resolved headers to be added to the resolved `RequestTemplate` preventing duplicate expression processing by using another new method `HeaderTemplate.literal` and `HeaderTemplate.appendLiteral` respectively. I chose this route as it isolates the change to be applied only after the original `HeaderTemplate` has been resolved. While it does expose new public `HeaderTemplate` APIs, I feel that is an OK trade off, allowing a new escape-hatch for situations where URI template processing is not acceptable for Header values.
Observed on versions: 11.2, 11.4
Not reproducible on version: 10.1.0
When passing a JSON string as
@Param
to@Headers
the string gets truncated.Example:
Gets truncated to:
Code to reproduce: https://github.com/daczczcz1/feign-bug-reproduction
The text was updated successfully, but these errors were encountered: