-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
feature: Control request parameter encoding with configuration #563
Conversation
@artgon could you please take a look at this when you get a chance? |
@artgon thoughts on this change? |
@artgon did you get a chance to look at this PR? |
@artgon Could you please take a look at this issue and let me know if you have any concerns? |
Could we please get reviews on this? |
This fix would be help for our efforts as well. |
We have the same issue , this fix will be really help us. |
@artgon any thoughts on this PR? |
@carl-mastrangelo could you please take a look at this? |
@sandy-adi I'll take a look. I discussed this briefly with @artgon but want to take a closer look before approving. |
false).getValue() | ||
){ | ||
try { | ||
name = URLDecoder.decode(name, "UTF-8"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I was going to comment on this, but it seems the issue is pre-existing. The name / value decoding should be done as all or nothing, because otherwise an exception in the value decoder could cause tearing.
Optional if you want to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on what has been currently implemented I think it should be a per key/value. Cause in cases where the query string has only key the encoding decoding of the query string varies. I think we should leave it as is.
catch (Exception e) { | ||
// do nothing | ||
if (!propertyFactory.getBooleanProperty( | ||
ZuulConstants.ZUUL_KEEP_ORIGINAL_QUERY_STRING_ENCODING, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is the correct thing to do. Preserving the encoding is fine, but the name and value still need to be validated. If this flag is off, all that needs to happen is the return value of URLDecoder should be discarded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the validation really be the responsibility of a proxy by default? especially when you are using OData style queries it's hard for a proxy to do the validation. I believe there should be an option for the service providers to not have the proxy/gateway validate the query string
zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java
Outdated
Show resolved
Hide resolved
if (StringUtils.isNotEmpty(entry.getValue())) { | ||
sb.append('='); | ||
sb.append(URLEncoder.encode(entry.getValue(), "UTF-8")); | ||
if (propertyFactory.getBooleanProperty(ZuulConstants.ZUUL_KEEP_ORIGINAL_QUERY_STRING_ENCODING,false).getValue()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this should not be dynamically changeable. You should capture the value when the query string is parsed originally, and use that to decide what the string value should be.
sb.deleteCharAt(sb.length() - 1); | ||
catch (UnsupportedEncodingException e) { | ||
// Won't happen. | ||
e.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I know it's not your fault, but since you are touching this code: This should be throwing an AssertionError(e), rather than printing to stderr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, but IMO it might be a breaking change for some of the users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO a proxy shouldn't be doing anything with the query parameters. It's arguable whether or not it should be a proxy concern. It's ok to have the ability to do that but it should definitely not be the default behavior. Especially for an open source implementation.
@@ -270,6 +285,18 @@ public boolean equals(Object obj) | |||
@RunWith(MockitoJUnitRunner.class) | |||
public static class TestUnit | |||
{ | |||
Properties testProperties = new Properties(); | |||
|
|||
private void setKeepOriginalEncoding(boolean keepOriginalEncoding) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: private methods should probably go at the bottom of the class to allow reading the test code from top to bottom.
Also, to be honest, I'm not that excited about this change. Query parameter processing is something that isn't well defined, and different people think it should do different things. I'm wondering if it would be a better idea to make the HttpQueryParams parsing pluggable, using the existing class as the default? |
3bf6efd
to
c66d3fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, to be honest, I'm not that excited about this change. Query parameter processing is something that isn't well defined, and different people think it should do different things. I'm wondering if it would be a better idea to make the HttpQueryParams parsing pluggable, using the existing class as the default?
The HttpQueryParams is implemented as a concrete class, if it was implemented as an interface that change would have been easy to do. I'd like to re-iterate that a proxy component should not be dealing with modifying query parameters like the way it's being done right now at least not the default behavior. The default behavior should be to just pass through.
Having said that is there a better way to do this, I've to think about it. I'm all for making it better. But would really appreciate if we can come to a closure on this PR and tackle that outside this PR. We ran into the issue with query string parsing late in the game and we never thought zuul would be modifying the query string. Right now we are having to maintain our own fork so we can keep this logic.
catch (Exception e) { | ||
// do nothing | ||
if (!propertyFactory.getBooleanProperty( | ||
ZuulConstants.ZUUL_KEEP_ORIGINAL_QUERY_STRING_ENCODING, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the validation really be the responsibility of a proxy by default? especially when you are using OData style queries it's hard for a proxy to do the validation. I believe there should be an option for the service providers to not have the proxy/gateway validate the query string
sb.deleteCharAt(sb.length() - 1); | ||
catch (UnsupportedEncodingException e) { | ||
// Won't happen. | ||
e.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, but IMO it might be a breaking change for some of the users.
sb.deleteCharAt(sb.length() - 1); | ||
catch (UnsupportedEncodingException e) { | ||
// Won't happen. | ||
e.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO a proxy shouldn't be doing anything with the query parameters. It's arguable whether or not it should be a proxy concern. It's ok to have the ability to do that but it should definitely not be the default behavior. Especially for an open source implementation.
zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java
Outdated
Show resolved
Hide resolved
false).getValue() | ||
){ | ||
try { | ||
name = URLDecoder.decode(name, "UTF-8"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on what has been currently implemented I think it should be a per key/value. Cause in cases where the query string has only key the encoding decoding of the query string varies. I think we should leave it as is.
@carl-mastrangelo do you have a better alternative to this? Would you be able to work on it? It will be greatly appreciated if you could fix this problem. Honestly a proxy should not be doing what is happening in this class here. |
This address the problem cited in #215