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

addEncodedQueryParameter is not working as expected #2623

Closed
nezen opened this Issue Jun 14, 2016 · 11 comments

Comments

7 participants
@nezen

nezen commented Jun 14, 2016

When I use addEncodedQueryParameter, I want to leave the equal sign as what it is, but it's always encoded as %3D.
Some other guys seem to have this problem as well [https://github.com/square/retrofit/issues/1199]

@Alisunov

This comment has been minimized.

Show comment
Hide comment
@Alisunov

Alisunov Jun 15, 2016

Hi! I've got the same problem and have looked into okhttp source and found the problem.
addEncodedQueryParameter() does encode keys and values of the url, but does not re-encode "%" symbol.

So, one of the solutions is to use @Query("fieldName") List<String> values

Alisunov commented Jun 15, 2016

Hi! I've got the same problem and have looked into okhttp source and found the problem.
addEncodedQueryParameter() does encode keys and values of the url, but does not re-encode "%" symbol.

So, one of the solutions is to use @Query("fieldName") List<String> values

@KChernenko

This comment has been minimized.

Show comment
Hide comment
@KChernenko

KChernenko Jun 17, 2016

I faced with the similar problem: symbols = and & in the @QueryMap which are passed as a part of values are always encoded.

KChernenko commented Jun 17, 2016

I faced with the similar problem: symbols = and & in the @QueryMap which are passed as a part of values are always encoded.

@JakeWharton

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Jun 17, 2016

Collaborator

That is working as intended. Those are illegal characters in a value since
they are separators. We are canonicalizing the value to work around this.

On Fri, Jun 17, 2016, 3:13 AM Constantine notifications@github.com wrote:

I faced with the similar problem: symbols =and & in the @QueryMap which
are passed as a part of values are always encoded.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2623 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEEEdjLo4PKvw8xUV3GEZD1_g9yAs7nks5qMkkpgaJpZM4I05xJ
.

Collaborator

JakeWharton commented Jun 17, 2016

That is working as intended. Those are illegal characters in a value since
they are separators. We are canonicalizing the value to work around this.

On Fri, Jun 17, 2016, 3:13 AM Constantine notifications@github.com wrote:

I faced with the similar problem: symbols =and & in the @QueryMap which
are passed as a part of values are always encoded.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2623 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAEEEdjLo4PKvw8xUV3GEZD1_g9yAs7nks5qMkkpgaJpZM4I05xJ
.

@swankjesse swankjesse closed this Jun 25, 2016

@Ginkosama

This comment has been minimized.

Show comment
Hide comment
@Ginkosama

Ginkosama Sep 26, 2016

Well, this does work as intended IF you're using a server that does not allow an equal symbol to be something else than a separators... We are obviously working with a different user case scenario...

I'm facing the problem of = being encoded while i don't want it to be...

I can understand the current idea behind encoded=true, not re-encoding already encoded values... but then clearly a second level tag is needed to completely avoid to encode the value passed...

Why do you feel the need to force us to work with the classic HTTP RFC ?

Ginkosama commented Sep 26, 2016

Well, this does work as intended IF you're using a server that does not allow an equal symbol to be something else than a separators... We are obviously working with a different user case scenario...

I'm facing the problem of = being encoded while i don't want it to be...

I can understand the current idea behind encoded=true, not re-encoding already encoded values... but then clearly a second level tag is needed to completely avoid to encode the value passed...

Why do you feel the need to force us to work with the classic HTTP RFC ?

@Ginkosama

This comment has been minimized.

Show comment
Hide comment
@Ginkosama

Ginkosama Sep 26, 2016

@Alisunov could you please develop on how to use a List to work around this issue ? I've tried but it still got the same behavior.

Ginkosama commented Sep 26, 2016

@Alisunov could you please develop on how to use a List to work around this issue ? I've tried but it still got the same behavior.

@swankjesse

This comment has been minimized.

Show comment
Hide comment
@swankjesse

swankjesse Sep 27, 2016

Member

You can use Builder.encodedQuery() when you want to retain = characters.
https://square.github.io/okhttp/3.x/okhttp/okhttp3/HttpUrl.Builder.html#encodedQuery-java.lang.String-

Member

swankjesse commented Sep 27, 2016

You can use Builder.encodedQuery() when you want to retain = characters.
https://square.github.io/okhttp/3.x/okhttp/okhttp3/HttpUrl.Builder.html#encodedQuery-java.lang.String-

@Ginkosama

This comment has been minimized.

Show comment
Hide comment
@Ginkosama

Ginkosama Sep 27, 2016

No you can see here that it will encode it anyway, it only does not re-encode what's already encoded.

I ended up having to use an interceptor to force-decode the = characters... which is ugly...

Ginkosama commented Sep 27, 2016

No you can see here that it will encode it anyway, it only does not re-encode what's already encoded.

I ended up having to use an interceptor to force-decode the = characters... which is ugly...

@swankjesse

This comment has been minimized.

Show comment
Hide comment
@swankjesse

swankjesse Sep 27, 2016

Member

@Ginkosama false. Builder.encodedQuery() will not encode an incoming = charager.

Member

swankjesse commented Sep 27, 2016

@Ginkosama false. Builder.encodedQuery() will not encode an incoming = charager.

@Ginkosama

This comment has been minimized.

Show comment
Hide comment
@Ginkosama

Ginkosama Sep 28, 2016

You're correct, its using QUERY_ENCODE_SET as parameter to canonicalize(), which does not contains the = character !

Thanks, I will try to use it, but will it require to build a different retrofit instance object or there is a way to pass it when calling an API endpoint ?

Ginkosama commented Sep 28, 2016

You're correct, its using QUERY_ENCODE_SET as parameter to canonicalize(), which does not contains the = character !

Thanks, I will try to use it, but will it require to build a different retrofit instance object or there is a way to pass it when calling an API endpoint ?

@swankjesse

This comment has been minimized.

Show comment
Hide comment
@swankjesse

swankjesse Sep 28, 2016

Member

Retrofit won’t be able to compose a query for you this way. You’ll need to compose it manually and provide an HttpUrl instance to Retrofit.

Member

swankjesse commented Sep 28, 2016

Retrofit won’t be able to compose a query for you this way. You’ll need to compose it manually and provide an HttpUrl instance to Retrofit.

@NeLk42

This comment has been minimized.

Show comment
Hide comment
@NeLk42

NeLk42 Sep 12, 2017

A very simple solution is to pass the value encoded and then add the encoded = true flag to retrofit.

String item = "MTUwNTIyODgxMDg4Mw==";

encodedItem = URLEncoder.encode(item, "utf-8");

@Query(value = "item", encoded = true) String item

This way when the time comes it'll decode it.

NeLk42 commented Sep 12, 2017

A very simple solution is to pass the value encoded and then add the encoded = true flag to retrofit.

String item = "MTUwNTIyODgxMDg4Mw==";

encodedItem = URLEncoder.encode(item, "utf-8");

@Query(value = "item", encoded = true) String item

This way when the time comes it'll decode it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment