I'm encoding a query parameter using GWT's com.google.gwt.http.client.URL.encode() method, but have found I can't use URL.decode() on the server to decode it because the implementation isn't available (I suspect it uses the javascript client side implementation). I get...
java.lang.UnsatisfiedLinkError: com.google.gwt.http.client.URL.decodeImpl(Ljava/lang/String;)Ljava/lang/String;
Can someone suggest what I'm supposed to use server side to decode the encoded string?
I solved my problem this way: on the client side, I encode the parameters using com.google.gwt.http.client.URL.encodeQueryString(), like:
URL.encodeQueryString(param)
On the server side, I get the parameters using the ServletRequest methods, like:
String myParam = req.getParameter("myparam");
PS I initially +1'd Riley Lark's answer, but then I got some problems with some characters too... Letting the ServletRequest do the job will handle all character's encoding for you.
See Decoding international chars in AppEngine
java.net.URLDecoder is implemented on AppEngine and works perfectly with com.google.gwt.http.client.URL.encode().
If you're not willing to use gwt-rpc you can encode/decode with Base64. Check this link for a gwt implementation of the Base64 encoder/decoder. Then all you have to do is Base64.encode(yourParameterValue) before sending the request to the server and Base64.decode(request.getParameter(yourParameterName)) on the backend right after receiving the request.
cheers!
Related
I'm getting a body hash mismatch when the POST body of an XML web service request contains international characters.
From what I've read, it sounds like international characters in a POST body have to be encoded before calculating the OAuth body hash. UTF-8 for CAFÉ of "CAF%c3%89" doesn't seem to work with the MasterCard Match web service. I'm having trouble with the tool we're using (iWay Service Manager) re-interpreting "CAFÉ" back to "CAFÉ". Before I figure out how to squeeze an encoder in before the OAuth step, I was hoping to confirm with someone who had dealt with this issue. What is the proper encoding to use on a POST body with international characters (or is my problem likely to be something else)?
For calculating MasterCard OAuth body hash, the recommended encoding is UTF-8. Also the Core SDK made available by MasterCard uses UTF-8 encoder to encode oauth_body_hash.
When sending a request via Zuul to a client, Zuul seems to change the query String. More specifically, if the client should receive an url-encoded query String, Zuul decodes the query String once. Here is a concrete example:
If "http://localhost:8080/demo/demo?a=http%3A%2F%2Fsomething/" is sent to the client, the client receives as a query String "a=http://something/".
Looking into Zuul`s code, the function "buildZuulRequestQueryParams" uses "HTTPRequestUtils.getInstance().getQueryParams();" which decodes the query String.
Is this a desired feature or a bug?
Zuul actually offers a flag to disable this behavior.
8.9 Query String Encoding
When processing the incoming request, query params are decoded so that they can be available for possible modifications in Zuul filters. They are then re-encoded the backend request is rebuilt in the route filters. The result can be different than the original input if (for example) it was encoded with Javascript’s encodeURIComponent() method. While this causes no issues in most cases, some web servers can be picky with the encoding of complex query string.
To force the original encoding of the query string, it is possible to pass a special flag to ZuulProperties so that the query string is taken as is with the HttpServletRequest::getQueryString method, as shown in the following example:
application.yml.
zuul:
forceOriginalQueryStringEncoding: true
[Note] This special flag works only with SimpleHostRoutingFilter.
Also, you loose the ability to easily override query parameters with
RequestContext.getCurrentContext().setRequestQueryParams(someOverriddenParameters),
because the query string is now fetched directly on the original
HttpServletRequest.
8. Router and Filter: Zuul
I was facing the same issue yesterday. I think it's related to this pull request. A faster way to solve this issue (without wait for PR get merged) is rewrite the classes in your own project using the same package and class name to override the framework class.
I ran into the same issue recently. Submitted a PR to Netflix/Zuul. Basically adding the same ability that's currently available on spring cloud gateway to Netflix. Hoping it'll get addressed soon.
If accepted, you could pretty much add a config to keep the original uri encoding
zuul.keepOriginalQueryStringEncoding=true
first of all I'd like to thank the team for this amazing project, it is indeed exiting to be able to start writing server-side software in Swift.
I'm successfully running a POC using PerfectServer on an Ubuntu VM and working on the API to interact with the mobile client.
There is one aspect I didn't quite understand yet, and that is accessing the request body data from my PerfectServer Handler.
Here is the workflow I have in mind:
The client submits a POST request to PerfectServer including some
JSON encoded body data
Once that hits the "valuesForResponse:" of
my server side Handler, I retrieve the WebRequest representation of
my request successfully
The request object does expose a many
properties of the HTTP request, including headers and the url-like
formatted query parameters.
Unfortunately, I cannot see a way to retrieve the underlying request body data. I would expect that to be some kind of public properties exposing the raw data that my handle can retrieve and decode in order to process the request.
The only example provided in the Examples workspace that comes with the project and sends a POST request that includes a body is in the project Authenticator. Here the HTTP body part takes the form os a UTF-8 encoded string where the values are query-params-like formatted.
name=Matteo&password=mypassword
This gets somehow exposed on the server handler by the WebRequest "param" property, that in the inner implementation of HTTPServer seems to expect an "&" separated string of key-values:
What I would expect is to have a way to provide body data in whatever form / encoding needed, in my case a JSON form:
{"name":"Matteo", "password":"psw"}
and be able to access that data from the WebRequest in my handler, decode it and use it to serve the request.
To summarise, I assume you could say that a WebRequest.bodyData public property is what I am after here :).
Is there something I am missing here?
Thanks in advance for any clarification!
I'm busy with web service and an iOS app. So far I haven't had that many issues. However, there is a web service that needs the final URL request to be in a certain format. Something along the lines of:
...?IncludedUserIds[]=1357213,286476&..
These parameters are constructed from an NSDictionary and NSString. Now when I add the comma - the end URL that makes the request ends up like this:
..?IncludedUserIds=%5B%5D1357213%2C286476&...
It seems that AFNetworking 2.0 has converted the square brackets into =%5B%5D and the comma into: %2C
Obviously, the web service has no idea what this means and fails.
Is there a way to keep the final Url as I need it to be? Why do these conversions happen and where can I learn more about this sort of thing?
AFNetworking keep the final url encoded, that is the best way, since you could have special characters in you query string that could break all. Instead, you should decode the url server side, for example in PHP you have methods, like urldecode or rawurldecode (eg: 'foo%20bar%40baz' ->'foo bar#baz'), or in ASP it should be kept automatically.
Hope it helps
Do I need to encode strings (eg URL) I pass as a POST form parameter?
Ie I want to pass a URL I have to my web application (ruby on rails) as one of the form parameters. So are there any potential characters in a URL/URI that would need to be encoded? Or perhaps rails would handle this anyway?
Do I need to encode strings (eg URL) I pass as a POST form parameter?
That depends on what you're using to create/send your POST request. If you're directly creating the request body yourself, then yes you would have to URL-encode each parameter:
POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
foo=bar&url=http://www.example.com/url?innerparameter1=1&innerparameter2=2
this is no good:innerparameter2 is actually a parameter of the outer form-encoded string. It would need encoding, which would look like:
foo=bar&url=http%3A//www.example.com/url%3Finnerparameter1%3D1%26innerparameter2%3D2
If, however, you are using something higher-level to make the POST request, and passing in some kind of mapping of parameter strings, I would expect that component to take care of the URL-encoding for you.
Code?
As bobince mentions, you need to encode any data that you're passing as URL parameters. Often whatever library you're using will take care of this. This applies to all HTTP requests BTW.
For example, an API has an endpoint GET /sites/:name.
Using cURL it should look like
curl http://example.com/sites/google%2Ecom
In Ruby/Rails, you can use URI.encode and URI.decode:
>> URI.encode('google.com', /\W/)
"google%2Ecom"
>> URI.decode('google%2Ecom')
"google.com"
As a general statement, if you emit programmatic or user input data to an HTML page, you should encode it for HTML. Bear in mind that URLs often have the & character and that should be encoded, even if browsers appear to handle it okay.
I'm not a Ruby guy, so I don't know how you do that in Ruby, nor am I familiar with Ruby on Rails to say if it will do it (though I would be a little surprised by that), but the guideline I suggest isn't language specific.