Skip to content

Attempt to fix truncated json literals in header values#1638

Closed
sm0217 wants to merge 5 commits into
OpenFeign:masterfrom
sm0217:master
Closed

Attempt to fix truncated json literals in header values#1638
sm0217 wants to merge 5 commits into
OpenFeign:masterfrom
sm0217:master

Conversation

@sm0217

@sm0217 sm0217 commented Jun 24, 2022

Copy link
Copy Markdown

Fix for #1464

Attempted a simple fix for the problem where If the value of header, body, queryparam etc starts with {, check if its a json literal before attempting to consider it as an expression.

Assuming unit tests cover all the cases, this fix works as expected for json literals. Need help identifying if this will impact any other expressions.

(Too many file changes because of license header. Changes only in feign core pom, Template and HeaderTemplateTest)

@sm0217 sm0217 marked this pull request as draft June 24, 2022 15:10
@sm0217 sm0217 marked this pull request as ready for review June 24, 2022 15:17
@sm0217

sm0217 commented Jun 24, 2022

Copy link
Copy Markdown
Author

@velo For #1464

@velo velo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry mate, we can't have org.json on core.... if that is really need, need to be extracted into a new API and an implementation outside core must be created using org.json, as for core, it must continue clean of dependencies.

Comment thread core/pom.xml

<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry mate, this is not going to happen.

feign core shall have no dependencies

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternate would be use regex to validate the json string without any external dependencies. I can already see a feign-json library which uses org.json to encode/decode json. I assume its the right place to add the json literal validation. But we would still need to add the feign-json library into feign-core to use the implementation.

@velo velo Jun 28, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all modules have multiple dependecies.... feign-core does not

But we would still need to add the feign-json library into feign-core to use the implementation

sorry, that won't be approved.

String chunk = tokenizer.next();

if (chunk.startsWith("{")) {
if (chunk.startsWith("{") && !isValidJsonLiteral(fragment)) {

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@velo This is the fix I think we need to resolve this issue. Check if the string is a json literal before parsing it as a template. So if you agree with this solution and I have to add this check here, what would be the best approach please? Open for suggestions.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the regex option you proposed?

@sm0217 sm0217 Jun 28, 2022

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try. The regex looks a bit complicated and yet to confirm if it breaks the template string. Let me add that with a few tests and update the PR. However I must add using a library is more elegant and remove complicated stuff under the hood which we don't want to implement ourself.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if you add a new boolean to @Header(expression = false) default it to true and then change this if to:

if (chunk.startsWith("{") && header.expression()) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feel free to pick any other name besides expression

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer this approach. Let’s add a property to the header annotation indicating that it should be treated like a literal. What about naming the property “literal” and be a Boolean?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will avoid any regular expressions and simplify the logic to be if “literal” is true, just render otherwise, resolve the expression. There should be a “Literal” type I think in the template package. I think.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remember annotation isn't the only way of setting the header

@sm0217 sm0217 Jun 29, 2022

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. This will avoid any assumption about the expression/literal.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although adding a variable like literal in Headers annotation wouldn't always be right since headers values is a string array, it's possible one of header has an expression and one is a literal. A variable would only work out if we can tailor the new variable for every header added to the array. That will be an expensive change.

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

Successfully merging this pull request may close these issues.

4 participants