Skip to content
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

Encoding issue for query parameter #1133

Closed
ehildebrandt opened this issue Dec 16, 2019 · 5 comments · Fixed by #1138
Closed

Encoding issue for query parameter #1133

ehildebrandt opened this issue Dec 16, 2019 · 5 comments · Fixed by #1138
Assignees
Labels
bug Unexpected or incorrect behavior feedback provided Feedback has been provided to the author

Comments

@ehildebrandt
Copy link

With version 10.2.3 the URL encoding logic changed (see #882).

It seems that in some cases, the query parameters are not encoded correctly. Some special characters like, e.g. equal sign (=) or quotes ('), are not encoded.

Here an example:
given query parameter: "select * from foo where bar = '123'"
expected encoded query parameter: "select%20%2A%20from%20foo%20where%20bar%20%3D%20%27123%27"
actual encoded query parameter: "select%20*%20from%20foo%20where%20bar%20=%20'123'"

@switchYello
Copy link
Contributor

switchYello commented Dec 19, 2019

can you given a simple test case,i don‘t understand.
i test here,

        String a = "select * from foo where bar = '123'";
        System.out.println(UriUtils.encode(a));

result

select%20%2A%20from%20foo%20where%20bar%20%3D%20%27123%27

@ehildebrandt
Copy link
Author

ehildebrandt commented Dec 20, 2019

Test code:
String a = "select * from foo where bar = '123'"; System.out.println(UriUtils.queryEncode(a, Charsets.UTF_8));

result:
select%20*%20from%20foo%20where%20bar%20=%20'123'

This is an issue for clients using SpringMvcContract like e.g.:
@RequestMapping(value = "/some-path/", method = GET, consumes = APPLICATION_JSON_VALUE, produces = APPLICATION_JSON_VALUE) QueryResponse<T> query(@NonNull @RequestParam("q") String query);

@kdavisk6
Copy link
Member

From what I can see, the issue you are experiencing is due to inconsistent encoding specifically on a query string. The = character is valid when present within the query segment of a url. We recognize this and leave the character as is during template expansion.

In the near term, my recommendation is to encode the = character in the string before submitting it.

I'll associate this issue with a number of other odd encoding issues that I am currently working on.

@kdavisk6 kdavisk6 added bug Unexpected or incorrect behavior feedback provided Feedback has been provided to the author labels Dec 23, 2019
kdavisk6 added a commit to kdavisk6/feign that referenced this issue Dec 26, 2019
Fixes OpenFeign#1123, Fixes OpenFeign#1133, Fixes OpenFeign#1102

Ensures that all expressions are fully-encoded before being
manipulated during template expansion.  This allows parameters
to include reserved values and result in properly encoded
results.

Additionally, `Iterable` values are now handled in accordance
with RFC 6570 allowing for the specified `CollectionFormat` to
be applied correctly.
kdavisk6 added a commit to kdavisk6/feign that referenced this issue Dec 26, 2019
Fixes OpenFeign#1123, Fixes OpenFeign#1133, Fixes OpenFeign#1102, Fixes OpenFeign#1028

Ensures that all expressions are fully-encoded before being
manipulated during template expansion.  This allows parameters
to include reserved values and result in properly encoded
results.

Additionally, `Iterable` values are now handled in accordance
with RFC 6570 allowing for the specified `CollectionFormat` to
be applied and empty parameters to be expanded correctly as this
is the main use case that exhibited this issue.
@kdavisk6 kdavisk6 self-assigned this Dec 26, 2019
kdavisk6 added a commit to kdavisk6/feign that referenced this issue Dec 27, 2019
Fixes OpenFeign#1123, Fixes OpenFeign#1133, Fixes OpenFeign#1102, Fixes OpenFeign#1028

Ensures that all expressions are fully-encoded before being
manipulated during template expansion.  This allows parameters
to include reserved values and result in properly encoded
results.

Additionally, `Iterable` values are now handled in accordance
with RFC 6570 allowing for the specified `CollectionFormat` to
be applied and empty parameters to be expanded correctly as this
is the main use case that exhibited this issue.
kdavisk6 added a commit that referenced this issue Dec 27, 2019
* Ensure Iterable values are encoded before template expansion

Fixes #1123, Fixes #1133, Fixes #1102, Fixes #1028

Ensures that all expressions are fully-encoded before being
manipulated during template expansion.  This allows parameters
to include reserved values and result in properly encoded
results.

Additionally, `Iterable` values are now handled in accordance
with RFC 6570 allowing for the specified `CollectionFormat` to
be applied and empty parameters to be expanded correctly as this
is the main use case that exhibited this issue.
@kdavisk6
Copy link
Member

@ehildebrandt I'm pretty sure I have this fixed. Can you please try 10.7.1-SNAPSHOT?

@ehildebrandt
Copy link
Author

It works. Thanks.

velo pushed a commit that referenced this issue Oct 7, 2024
* Ensure Iterable values are encoded before template expansion

Fixes #1123, Fixes #1133, Fixes #1102, Fixes #1028

Ensures that all expressions are fully-encoded before being
manipulated during template expansion.  This allows parameters
to include reserved values and result in properly encoded
results.

Additionally, `Iterable` values are now handled in accordance
with RFC 6570 allowing for the specified `CollectionFormat` to
be applied and empty parameters to be expanded correctly as this
is the main use case that exhibited this issue.
velo pushed a commit that referenced this issue Oct 8, 2024
* Ensure Iterable values are encoded before template expansion

Fixes #1123, Fixes #1133, Fixes #1102, Fixes #1028

Ensures that all expressions are fully-encoded before being
manipulated during template expansion.  This allows parameters
to include reserved values and result in properly encoded
results.

Additionally, `Iterable` values are now handled in accordance
with RFC 6570 allowing for the specified `CollectionFormat` to
be applied and empty parameters to be expanded correctly as this
is the main use case that exhibited this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected or incorrect behavior feedback provided Feedback has been provided to the author
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants