I have encountered an interesting behavior of GO Gin framework.
E.g. I have an endpoint GET which expects an ID, e.g. /users/1, while this works fine if you pass e.g. 1, during testing I have noticed that if you send /users/% it fails instantly and returns 400 Bad Request with content type text/plain; charset=utf-8.
Now all is ok, but the tricky part is that I want to handle this error with custom error message and I want to receive content type as application/json; charset=utf-8. But the problem is that I can't figure out where this request is rejected as in logs I can't see that it was even called and the route looks not called at all.
So my question is, how Gin handles bad uri query params like % and how it's possible to handle it in my own way?
Getting an issue when trying to call opentok/session/create api.
When calling the api through code i keep getting an error saying the connection has been closed. So I decided to try through postman and the error i'm getting back is a 500 internal server error and a message
{
"message": "Internal server error, working hard to fix it, sorry",
"code": -1
}
As far as I can see I have everything set correctly.
Headers, Body ]
I don't think this is a JWT issue as according to the documentation that would be a 403. https://tokbox.com/developer/rest/#session_id_production
Anyone experienced this or a similar issue before
The issue ended up being the content Content-Type header I had to set
Content-Type: application/x-www-form-urlencoded
Credit to #adrice727's comment for suggesting there might be an issue with the Content-Type header.
I am trying to do DELETE http request to an API ( I don't have access to the source code of it) but the API keeps responding with 406.
I tried to put "Accept" header any but the issue still the same, I see the headers are correct.
Any help is appreciated
I've been trying to fix this all day.
I got a Lambda function I'm trying to run when I make a POST request to the endpoint (configured with AWS API GATEWAY).
Everything runs fine, my options gets a 200 okay, my post gets a 200 okay and comes back with the data I want.
However when I get it back, it "thinks" it failed. I use JQuery for this project, and it comes back as the "fail" cb.
Looking at the console log the problem is quite clearly the following error:
XMLHttpRequest cannot load
https://xxxxxxxxx.execute-api.us-west-2.amazonaws.com/prod/createCustomer.
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:3000' is therefore not allowed
access.
a standard CORS issue. But nothing I do seems to work. I enabled CORS on the API gateway (before that the OPTIONS would fail). the 'Access-Control-Allow-Origin': is set to: '*' which should allow access from any origin. I of course deployed the new API.
I also tried not using CORS and instead enabling the AWS proxy thing, and having my response like this { statusCode, headers, body } but when doing that I get no response whatsoever.
I have absolutely no clue where to start attempting to fix this. I even tried a dirty jsonp method. But still same problem. :(
The only bit of data I can find on my request that doesn't seem okay, is this: x-cache:Miss from cloudfront
Here's the full response headers from the POST request:
content-length:2312
content-type:application/json
date:Thu, 23 Mar 2017 22:15:08 GMT
status:200
via:1.1 95a477af435073615179b256d8101334.cloudfront.net (CloudFront)
x-amz-cf-id:Hc6POYFO0HKB1xriSg2iH7O1po7ah926a4dQkgfSNBUZ460RoHRNuw==
x-amzn-requestid:2b5ed745-1016-11e7-b497-cb0a77cd1479
x-amzn-trace-id:Root=1-58d448ea-56717776eaa3f5389083e9ca
x-cache:Miss from cloudfront
Sadly as is quite obvious, the Access control headers aren't there... I assume that's the problem I'm desperately trying to fix. But I have no idea why since I set it to ' * ' during the Enable CORS step of this process.
I was able to get semi-close to a solution by manually creating a POST method (as opposed to "ANY"), then enabling CORS again, then turning on the PROXY on integration response, and set my response to: { statusCode, headers, body } This will come back as a successfull event and run the right callback function in my ajax call. However, using this method I get no data back from Lambda... despite having it in "body", all I receive is an empty object.
I don't really have a preference of using CORS or manually adding headers, that's fine I won't be updating this much. I just really really need to get it functioning :( Any help would be greatly appreciated.
If you got x-cache:Miss from cloudfront from your API, it is fine because API Gateway doesn't enable the edge cache on the cloudfront side. If you want CORS to work with Lambda proxy integration, you can return the status code and the headers, like,
{
"statusCode": 200,
"headers": { "Access-Control-Allow-Origin": "<domains you need>" }
}
Then, it will be like an empty response from the client side.
I have now idea why, but I was able to get it working. Using the following steps:
Enable CORS,
Deploy API, (can probably be skipped...)
Manually add POST method,
Enable Proxy on Integration response,
Deploy API again
change callback response to format: { statusCode: 200, headers: {}, body: {} }
use JSON.parse() to parse your payload.
This is definitely not a perfect answer. For some reason turning on the Proxy modified how my Lambda function received data, so I had to Stringify it to not cause an error. I can't offer an explanation why this happened.
The headers I used were:
"Access-Control-Allow-Methods": "DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT",
"Access-Control-Allow-Origin": "*"
A better solution to this would also be a way to do this just using CORS. As you don't have to manually insert headers in all your responses. But I couldn't get that working. So please, if someone knows a better solution to this post it!
I have a problem while sending a message via Jersey client on Mandrill API. I use Jersey client as follows:
ClientBuilder.newClient()
.register(JacksonJsonProvider.class)
.target(“https://mandrillapp.com/api/1.0/messages/send.json”)
.request(MediaType.APPLICATION_JSON_TYPE)
.post(Entity.json(methodEntity));
Below you can see logged headers, method and content of the API request.
POST https://mandrillapp.com/api/1.0/messages/send.json
Accept: application/json
Content-Type: application/json
{"message":{"subject":"Hello World!","text":"Really, Im just saying hi from Mandrill!","to":[{"email":"marcel#xxxx.com","name":"Marcel cccc","type":"to"}],"headers":{},"tags":["test"],"from_email":"info#xxxxx.com","auto_text":true,"preserve_recipients":false},"async":false,"key":"EWIBVEIOVBVOIEBWIOVEB"}
In response to this request I keep receiving following message:
[{"email":"marcel#XXXX.com","status":"rejected","_id":"0ea5e40fc2f3413ba85b765acdc5f17a","reject_reason":"invalid-sender"}]
I do not know what the issue may be, from some posts I figured out I must use UTF-8 to encode my message and headers. But setting encoding to UTF-8 did not do much good. Otherwise the payload seems fine to me and moreover I found on forums that invalid sender can mean any other kind of issue (not just invalid sender which is sad).
I had exactly same problem with
"reject_reason":"invalid-sender"
You probably check already similar question Mandrill “reject_reason”: “invalid-sender”
Try it if it helps. I realize that you also missing header parameter in your request
e.g. User-Agent: Mandrill-myclient/1.0
Please try also add this parameter to your Jersey Client setup as following:
ClientBuilder.newClient()
.register(JacksonJsonProvider.class)
.target(“https://mandrillapp.com/api/1.0/messages/send.json”)
.request(MediaType.APPLICATION_JSON_TYPE)
.header("User-Agent", "Mandrill-myclient/1.0")
.post(Entity.json(methodEntity));
Does it help?