You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
When using a @Rest interface with a method that takes URL parameters, such as:
@Get("/search/keyword/{keyword}/mode/{mode}")
public SearchResponse search(String keyword, String mode);
Using any characters that are considered safe for use in URLs, such as / and &, these characters will not be encoded. For example, search("any/key", "alpha") will result in the following URL:
/search/keyword/any/key/mode/alpha
Which obviously will result in an error, because now the parameters are "any" and "mode". Expected behaviour: the URL parameters are escaped, like this:
/search/keyword/any%2Fkey/mode/alpha
Encoding the parameter in my own code doesn't solve this issue, because %2F wil be encoded in to %252F. Changing the input from String to android.net.Uri or java.net.URI to prevent encoding also doesn't make any difference. Using the Spring RestTemplate, you could just pass an UriTemplate to prevent encoding, but that doesn't seem to be possible here.
Is it possible to either force it to encode everything in the parameter, as I'd expect, or force it not to encode anything, so that the user would have to encode it?
Using AA 3.3.2 and Spring Android REST template 2.0.0M3
In AA 4.0, we added the @Path annotation which is mandatory for path parameters. It does not support encoding yet, but we plan to add a parameter to encode the url variable, just like Retrofit does.
Activity
WonderCsabo commentedon Jan 12, 2016
In AA 4.0, we added the
@Pathannotation which is mandatory for path parameters. It does not support encoding yet, but we plan to add a parameter to encode the url variable, just like Retrofit does.gauravsak commentedon Dec 30, 2016
@WonderCsabo I think your answer seems enough. Should this issue be closed then? Thanks!
WonderCsabo commentedon Dec 30, 2016
@gauravsak we should add
encodingparameters in the future.Mehly commentedon Feb 6, 2017
Is there anything new on this issue/feature? Any plans on when this feature is going to be released?
WonderCsabo commentedon Feb 6, 2017
We have limited time to develop new features, contributions are always welcomed and get reviewed quickly.