feature: Control request parameter encoding with configuration #563

sandy-adi · 2019-03-25T21:47:04Z

This address the problem cited in #215

sandy-adi · 2019-03-27T16:49:27Z

@artgon could you please take a look at this when you get a chance?

sandy-adi · 2019-04-04T02:27:40Z

@artgon thoughts on this change?

sandy-adi · 2019-04-18T22:55:02Z

@artgon did you get a chance to look at this PR?

sandy-adi · 2019-04-30T15:02:42Z

@artgon Could you please take a look at this issue and let me know if you have any concerns?

sandy-adi · 2019-07-15T20:11:50Z

Could we please get reviews on this?

mmaio · 2019-07-17T21:05:22Z

This fix would be help for our efforts as well.

rajc28 · 2019-07-18T07:46:23Z

We have the same issue , this fix will be really help us.

sandy-adi · 2019-09-04T18:27:47Z

@artgon any thoughts on this PR?

sandy-adi · 2019-09-05T16:02:28Z

@carl-mastrangelo could you please take a look at this?

carl-mastrangelo · 2019-09-06T09:09:45Z

@sandy-adi I'll take a look. I discussed this briefly with @artgon but want to take a closer look before approving.

carl-mastrangelo · 2019-09-06T09:13:28Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

+                    false).getValue()
+                ){
+                    try {
+                        name = URLDecoder.decode(name, "UTF-8");


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.

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 · 2019-09-06T09:14:47Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

-                catch (Exception e) {
-                    // do nothing
+                if (!propertyFactory.getBooleanProperty(
+                    ZuulConstants.ZUUL_KEEP_ORIGINAL_QUERY_STRING_ENCODING,


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.

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

carl-mastrangelo · 2019-09-06T09:15:59Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

-                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()) {


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.

carl-mastrangelo · 2019-09-06T09:17:47Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

-                sb.deleteCharAt(sb.length() - 1);
+            catch (UnsupportedEncodingException e) {
+                // Won't happen.
+                e.printStackTrace();


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.

I thought about that, but IMO it might be a breaking change for some of the users.

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.

carl-mastrangelo · 2019-09-06T09:18:42Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

@@ -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) {


nit: private methods should probably go at the bottom of the class to allow reading the test code from top to bottom.

carl-mastrangelo · 2019-09-06T09:26:36Z

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?

sandy-adi

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.

sandy-adi · 2019-09-09T14:55:14Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

-                catch (Exception e) {
-                    // do nothing
+                if (!propertyFactory.getBooleanProperty(
+                    ZuulConstants.ZUUL_KEEP_ORIGINAL_QUERY_STRING_ENCODING,


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

sandy-adi · 2019-09-09T18:38:21Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

-                sb.deleteCharAt(sb.length() - 1);
+            catch (UnsupportedEncodingException e) {
+                // Won't happen.
+                e.printStackTrace();


I thought about that, but IMO it might be a breaking change for some of the users.

sandy-adi · 2019-09-09T18:40:14Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

-                sb.deleteCharAt(sb.length() - 1);
+            catch (UnsupportedEncodingException e) {
+                // Won't happen.
+                e.printStackTrace();


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

sandy-adi · 2019-09-09T19:32:12Z

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java

+                    false).getValue()
+                ){
+                    try {
+                        name = URLDecoder.decode(name, "UTF-8");


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.

sandy-adi · 2019-11-16T21:39:26Z

@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.

sandy-adi changed the title ~~feature: Control request parameter encoding with a configuration~~ feature: Control request parameter encoding with configuration Mar 25, 2019

sandy-adi mentioned this pull request Mar 25, 2019

Netflix Zuul query string encoding #215

Open

sandy-adi force-pushed the uri-encoding branch from 34ae8a2 to 92751bc Compare March 26, 2019 13:15

sandy-adi force-pushed the uri-encoding branch from 92751bc to 56216dc Compare March 28, 2019 14:10

sandy-adi changed the title ~~feature: Control request parameter encoding with configuration~~ feature: Control request parameter encoding with configuration Fixes #215 Apr 18, 2019

sandy-adi changed the title ~~feature: Control request parameter encoding with configuration Fixes #215~~ feature: Control request parameter encoding with configuration Jul 17, 2019

carl-mastrangelo self-requested a review September 6, 2019 09:08

carl-mastrangelo reviewed Sep 6, 2019

View reviewed changes

zuul-core/src/main/java/com/netflix/zuul/message/http/HttpQueryParams.java Outdated Show resolved Hide resolved

carl-mastrangelo reviewed Sep 6, 2019

View reviewed changes

feature: Control request parameter encoding with a configuration

c66d3fa

sandy-adi force-pushed the uri-encoding branch from 3bf6efd to c66d3fa Compare September 9, 2019 19:22

sandy-adi commented Sep 9, 2019

View reviewed changes

Merge branch '2.1' of github.com:Netflix/zuul into merge-upstream

dab8013

sandy-adi requested a review from carl-mastrangelo November 2, 2019 03:21

carl-mastrangelo closed this Nov 15, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feature: Control request parameter encoding with configuration #563

feature: Control request parameter encoding with configuration #563

sandy-adi commented Mar 25, 2019 •

edited

sandy-adi commented Mar 27, 2019

sandy-adi commented Apr 4, 2019

sandy-adi commented Apr 18, 2019

sandy-adi commented Apr 30, 2019

sandy-adi commented Jul 15, 2019

mmaio commented Jul 17, 2019

rajc28 commented Jul 18, 2019

sandy-adi commented Sep 4, 2019

sandy-adi commented Sep 5, 2019

carl-mastrangelo commented Sep 6, 2019

carl-mastrangelo Sep 6, 2019

sandy-adi Sep 9, 2019

carl-mastrangelo Sep 6, 2019

sandy-adi Sep 9, 2019

carl-mastrangelo Sep 6, 2019

carl-mastrangelo Sep 6, 2019

sandy-adi Sep 9, 2019 •

edited

sandy-adi Sep 9, 2019

carl-mastrangelo Sep 6, 2019

carl-mastrangelo commented Sep 6, 2019

sandy-adi left a comment

sandy-adi Sep 9, 2019

sandy-adi Sep 9, 2019 •

edited

sandy-adi Sep 9, 2019

sandy-adi Sep 9, 2019

sandy-adi commented Nov 16, 2019

feature: Control request parameter encoding with configuration #563

feature: Control request parameter encoding with configuration #563

Conversation

sandy-adi commented Mar 25, 2019 • edited

sandy-adi commented Mar 27, 2019

sandy-adi commented Apr 4, 2019

sandy-adi commented Apr 18, 2019

sandy-adi commented Apr 30, 2019

sandy-adi commented Jul 15, 2019

mmaio commented Jul 17, 2019

rajc28 commented Jul 18, 2019

sandy-adi commented Sep 4, 2019

sandy-adi commented Sep 5, 2019

carl-mastrangelo commented Sep 6, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandy-adi Sep 9, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carl-mastrangelo commented Sep 6, 2019

sandy-adi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandy-adi Sep 9, 2019 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandy-adi commented Nov 16, 2019

sandy-adi commented Mar 25, 2019 •

edited

sandy-adi Sep 9, 2019 •

edited

sandy-adi Sep 9, 2019 •

edited