I'm creating a JavaServer Faces project to send messages to my Android application as directed in https://github.com/google/gcm.
It works fine when I perform modal messaging in:
public static void main (String [] args) { sendMessage() }
But when I call the method to send messages from the web interface, the message appears in Android with faulty Vietnamese font.
I think the problem lies in the requests send from the server as notification. It seems like they are are properly encoded with the correct parameters. Please make sure that the requests are UTF-8 encoded where spaces are replaced by + symbol.
The URL encoding has a % symbol or a character and a two-character hex value corresponding to a UTF-8 character. This may differ from language to language.
Change to content type to specify the charset=UTF-8 and then encode the request likewise. Follow the instruction on the GCM docs.
The HTTP header must contain the following headers:
Authorization: key=YOUR_API_KEY
Content-Type: application/json for JSON; application/x-www-form-urlencoded;charset=UTF-8 for plain text.
Related
IIS will send back a 400 error if you send it two content-type headers, here is an example:
1: Content-type : application/json
2: Content-type : application/json; charset=utf-8;
Apache handles that and processes properly for json.
My reading of the w3c spec is that only a single Content-Type header is allowable. Arguably though both headers mean exactly the same thing as JSON in this case is as I understand it, UTF-8. So whose right here? IIS or Apache?
My app fails running on IIS, the Android lib I am using sends 2 headers if I give it my own and fails on IIS. So currently I'm locked into Apache.
I am passing the value "mine & mine" to query parameter a after encoding the value it showing as a="mine+%26+mine". In my local Weblogic 12c server i am able to retrieve the value properly. but when I push the changes to my dev server I am only getting the value a "mine". when I print the querystring I am seeing the value as a="mine+&+mine".
we are invoking the service from postman,android, ios & ARC.
you must replace + with %20, the result of mine & mine should be mine%20%26%20mine.
there is a full answer in here.
the error maybe occurs in the client or in the server. the server and client side decode parameters twice from query string. so then you need encode the & twice which result in %2526. the & symbol is a special symbol for separates http request parameters.
the weblogic decoding once automatically in the server side, so you need to check your sever & client where also does decoding.
I'm sending request body as
grant_type=password&username=username&password=7LQCz+ACVLqJYjR39MjVTQ==
from mobile app
but password is taking as 7LQCz ACVLqJYjR39MjVTQ==
The sending side is not URL encoding but the receiving side is URL decoding. Both sided need to agree in the used encodings.
I general it is not necessary to URL encode POST data.
I'm trying to use OkHttp on Android to connect to an API that uses Basic Http authentication, and even though I appear to be doing everything right, I'm getting a 401 Unauthorized error.
The API is configured a little strangely in that it apparently requires the username (Base64 encoded) to be included in the url; it will not accept a properly formatted "Authorization: Basic " header. So the request has to be formatted like this:
https://<username>:<password>#www.api.com/api/ver/1/method
Where "username" and "password" are the Base64 encoded username and password entered by the user.
When I take the URL being sent by OkHttp and try it directly with curl, it works. So I know that the username and password are correct, they are being encoded correctly, and the url is being constructed correctly. But when I try it in my app, I get a 401 Unauthorized error with a "Www-Authenticate" header. Which is exactly what it sends if I try it in Postman with the "Authorization" header instead of the username and password in the url.
Is it possible that OkHttp is trying to be smart here, and pulling the username and password out of the url and automatically generating an "Authorization" header before sending the request? If so, I'd like to stop it from doing that.
i'm sending an http request to the google reader api and getting an unusual response code. following the documentation, i've requested an auth code and included it in the header of every request. after performing the login, and getting an auth code, i tried accessing this url, which is part of the documentation:
http://www.google.com/reader/api/0/stream/items/contents
when i send the request, i get a 411 status code, which is supposed to mean "Length Required". the length, as i've found, is supposed to be the length, in octets, of the message body. there is no message body in this request. there is only a single header, the POST parameter i="item id" and the URL itself. i tried setting the "Content-Length" header to "0" and also to "-1" to no avail.
what's really interesting is that this same code worked fine before google changed their authorization procedure. it's apparent they've changed something else...
so my question is what EXACTLY would cause a 411 response code and how can i prevent it?
This error happens only with POST and PUT request types, as these two (sort of) expect to have a request body that includes the request parameters (plain textual as well as attachments).
However as the documentation suggests, this is largely an obsolete value, and realistically the web services should handle requests without relying on Content-Length.
So it's not the problem of a request sender, but it is (I would say) a bug on the service side.
Nevertheless, setting a Content-Length (mind the proper capitalisation) request header to 0 should be the workaround.