We used wso2esb 4..8.1.
We are facing issue when moved into the production some of the requests from client is getting 404 page not found error .Where as everything is working in dev environment
We are facing same issue like above description the difference is we are using F5 Hard ware load balance.
we are able to see request and response printed in wso2carbon.log but client is not getting response and resulting 404 error code.
Please be informed that this problem is happening only for certain requests only not for all.
We tried to reproduce this scenario using Jmeter and Soap UI but did not face this problem. Our doubt is response being dropped going through HLB.
Please suggest.
Related
For my Django project, I am using djstripe. Using test data, I have confirmed that payments are successful. However, when testing a webhook, I get errors of 404 and then it sometimes changes to 503 (for the same webhook). I am using Heroku free tier so I am not sure if that is the problem, or if I am configuring the webhooks entirely wrong (likely since this is my first project). Any help is appreciated.
Stripe endpoint I have as [heroku domain]/users/accounts/webhook/ and my project urls is path('users/accounts/', include('allauth.urls')),
404 means that the URL you've provided to Stripe for your webhook is not found on/by your server; this is something you'll need to investigate on your end.
If you share more code - like specifically the code containing your route for the webhook - that might be useful for helping you diagnose the issue here.
i have found some solutions.
1- copy response of HTML tags and convert it to an HTML Page. you will be able to see the error raising from your platform which is failing the webhook.
2- Debug the each line of webhook view/code.
I have been trying to post some achievements in game with following code:
FB.API(FB.UserId +"/"+achievementType,
Facebook.HttpMethod.POST,
AchievementCallback,formData);
but the result is sometimes posted on my activity log and sometimes it fails to post with the message
"Unknown SSL protocol error in connection to graph.facebook.com:8000" while sometimes it is sucessful with post ID. I have tested the achievement files from facebook API explorer and also from POSTMAN plugin and it successfully posted it using both of them with post ID. But when I try to post the achievement from Unity3d it fails sometimes and works sometimes. Does anyone know what i am doing wrong while posting using UnitySDK?
Note: I have hosted these files on Github. Example AchievementFileLink
If anyone has suggestion please let me know.
The workaround I found out for this is whenever the above error happens I again send the request in the callback method to post achievement and it gets published on my game activity successfully. This should not be the intended behaviour and is very bad practice but for time being ill take this as an answer.
I'm runny Jetty 9.0.6.v20130930 via Maven with the command mvn jetty:run.
Looking through my server logs, every couple of days I'm getting this message:
2014-01-28 00:57:47.659:WARN:oejh.HttpParser:qtp975361377-71: BadMessage: 400 No Host for HttpChannelOverHttp#66a7150e{r=0,a=IDLE,uri=-}
I haven't been able to replicate it, and it doesn't appear to happening in the vicinity of any other requests, which I would expect if there were someone using the site. What I'd like to know is what might be causing it, and what the user (if there is one) is seeing when it happens?
maybe somebody post streaming request to your website. for example: a websocket handshake request.
reference link:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=417589
I am trying a GET request from Facebook for a batch of ids using my app access token separated by a comma.
Please find below the call:
https://graph.facebook.com/?ids=1374186930,100005305471358,1516423103,100003031846875,100002939786624,100004705179654,522691095,100002893804783,100005269178084,1417831236,100004652521769,100003511989378,100002394692546,1646211152,1092931510,100000152985362,100004151552444,100004122698187,100001574061632,100005007584068&access_token=<my_app_access_token>&format=json
Facebook returns an error intermittently for some of these requests with an HTTP status code of 502.
I've tried fetching for these ids using the graph API explorer as well as the app access token later. They have been fetched properly. I have performed some research, but all issues of Facebook were related to open graph and 502 is "Bad Gateway Error". Since mine is not a web app, I cannot even refresh a browser to make the call again. This is a normal call made to Facebook API.
The error returned by Facebook is html which contains the following message:
"Sorry, something went wrong. We're working on getting this fixed as soon as we can."
Since they have given this response, I want to know if someone is facing this issue as well and if somebody could tell me, when this will be resolved.
This is affecting the other calls as well and there is a delay in the fetching.
Thanks in advance.
The Error 502 means that the message is too large. I do not know exactly the maximum size. Curiosity. What language are you using??
Good Bye
For a number of sites that are functioning normally, when I run them through the OpenGraph debugger at developers facebook com/tools/debug, Facebook reports that the server returned a 502 or 503 response code.
These sites are clearly working fine on servers that are not under heavy load. URLs I've tried include but are not limited to:
http://ac.mediatemple.net
http://freespeechforpeople.org
These are in fact all sites hosted by MediaTemple. After talking to people at MediaTemple, though, they've insisted that it must be a bug in the API and is not an issue on their end. Anyone else getting unexpected 500/502/503 HTTP response codes from the Facebook Debug tool, with sites hosted by MediaTemple or anyone else? Is there a fix?
Note that I've reviewed the Apache logs on one of these and could find no evidence of Apache receiving the request from Facebook, or of a 502 response etc.
Got this response of them:
At this time, it would appear that (mt) Media Temple servers are returning 200 response codes to all requests from Facebook, including the debugger. This can be confirmed by searching your access logs for hits from the debugger. For additional information regarding viewing access logs, please review the following KnowledgeBase article:
Where are the access_log and error_log files for my server?
http://kb.mediatemple.net/questions/732/Where+are+the+access_log+and+error_log+files+for+my+server%3F#gs
You can check your access logs for hits from Facebook by using the following command:
cat <name of access log> | grep 'facebook'
This will return all hits from Facebook. In general, the debugger will specify the user-agent 'facebookplatform/1.0 (+http://developers.facebook.com),' while general hits from Facebook will specify 'facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php).'
Using this information, you can perform even further testing by using 'curl' to emulate a request from Facebook, like so:
curl -Iv -A "facebookplatform/1.0 (+http://developers.facebook.com)" http://domain.com
This should return a 200 or 206 response code.
In summary, all indications are that our servers are returning 200 response codes, so it would seem that the issue is with the way that the debugger is interpreting this response code. Bug reports have been filed with Facebook, and we are still working to obtain more information regarding this issue. We will be sure to update you as more information becomes available.
So good news, is that they are busy with it solving it. Bad news, it's out of our control.
There's a forum post here of the matter:
https://forum.mediatemple.net/topic/6759-facebook-503-502-same-html-different-servers-different-results/
With more than 800 views, and recent activity, it states that they are working hard on it.
I noticed that https MT sites don't even give a return code:
Error parsing input URL, no data was scraped.
RESOLUTION
MT admitted it was their fault and fixed it:
During our investigation of the Facebook debugger issue, we have found that multiple IPs used by this tool were being filtered by our firewall due to malformed requests. We have whitelisted the range of IP addresses used by the Facebook debugger tool at this time, as listed on their website, which should prevent this from occurring again.
We believe our auto-banning system has been blocking several Facebook IP addresses. This was not immediately clear upon our initial investigation and we apologize this was not caught earlier.
The reason API requests may intermittently fail is because only a handful of the many Facebook IP addresses were blocked. The API is load-balanced across several IP ranges. When our system picks up abusive patterns, like HTTP requests resulting in 404 responses or invalid PUT requests, a global firewall rule is added to mitigate the behavior. More often than not, this system works wonderfully and protects our customers from constant threats.
So, that being said, we've been in the process of whitelisting the Facebook API ranges today and confirming our system is no longer blocking these requests. We'd still like those affected to confirm if the issue persists. If for any reason you're still having problems, please open up or respond to your existing support request