-
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
Encoding issue for query parameter #1133
Comments
can you given a simple test case,i don‘t understand. String a = "select * from foo where bar = '123'";
System.out.println(UriUtils.encode(a)); result
|
Test code: result: This is an issue for clients using SpringMvcContract like e.g.: |
From what I can see, the issue you are experiencing is due to inconsistent encoding specifically on a query string. The In the near term, my recommendation is to encode the I'll associate this issue with a number of other odd encoding issues that I am currently working on. |
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.
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.
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.
* 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.
@ehildebrandt I'm pretty sure I have this fixed. Can you please try 10.7.1-SNAPSHOT? |
It works. Thanks. |
* 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.
* 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.
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'"
The text was updated successfully, but these errors were encountered: