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
======== background =======
I have a RESTful API looks like "GET /product/productID" productID is a route parameter.
I build the GetRequest like below: GetRequest request = Unirest.get("http://localhost/product/{id}").routeParam("id", product_id);
======== problem =======
Assume product_id = "id/id"
If I print request.getUrl(), I get "id%2Fid". However, when the request get to my http server (nginx), it becomes "product/id/id"
Basically I think routeParam itself does convert "/" to percentage encoding, but the underlying httpclient implementation may altered this behavior.
Could you suggest any fix?
Link to this issue: #137
I investigated, and URL encoding of route parameters is generally not very good implemented. It uses the URLParamEncoder class instead of relying on existing encoding utilities. I also fail to see which encoding this class applies, let alone that is is just not working correctly.
Using query parameters however does use a different way of encoding, namely by calling URLEncoder.encode("value", "UTF-8"). The fact that this encoding is not variable, and that its encoding differs totally from encoding route parameters, are two red flags for me.
@kongfujianlong I recommend you do not use routeParam anymore. If you want to use unirest for now, then encode the route parameter yourself instead of relying on Unirest to do it for you.
I hope this gets fixed soon, it is a huge shortcoming and potential problem I just uncovered in our rest client. The only quick fix that I can propose is by replacing the URLParamEncodercall to a call to URLEncoder.encode, and then at least it will use the same encoding method as query parameters.
Using URLEncoder for URL encoding is probably not a good idea. URLEncoder is supposed to be used for HTML form encoding, which has slightly different rule than the URL encoding.
From #141
======== background =======
I have a RESTful API looks like "GET /product/productID" productID is a route parameter.
I build the GetRequest like below:
GetRequest request = Unirest.get("http://localhost/product/{id}").routeParam("id", product_id);
======== problem =======
Assume product_id = "id/id"
If I print request.getUrl(), I get "id%2Fid". However, when the request get to my http server (nginx), it becomes "product/id/id"
Basically I think routeParam itself does convert "/" to percentage encoding, but the underlying httpclient implementation may altered this behavior.
Could you suggest any fix?
Link to this issue: #137
I investigated, and URL encoding of route parameters is generally not very good implemented. It uses the URLParamEncoder class instead of relying on existing encoding utilities. I also fail to see which encoding this class applies, let alone that is is just not working correctly.
Using query parameters however does use a different way of encoding, namely by calling URLEncoder.encode("value", "UTF-8"). The fact that this encoding is not variable, and that its encoding differs totally from encoding route parameters, are two red flags for me.
@kongfujianlong I recommend you do not use routeParam anymore. If you want to use unirest for now, then encode the route parameter yourself instead of relying on Unirest to do it for you.
I hope this gets fixed soon, it is a huge shortcoming and potential problem I just uncovered in our rest client. The only quick fix that I can propose is by replacing the URLParamEncodercall to a call to URLEncoder.encode, and then at least it will use the same encoding method as query parameters.
Using URLEncoder for URL encoding is probably not a good idea. URLEncoder is supposed to be used for HTML form encoding, which has slightly different rule than the URL encoding.
Please see here http://stackoverflow.com/questions/14321873/java-url-encoding-urlencoder-vs-uri
The text was updated successfully, but these errors were encountered: