We are coding Plugins for Roundcube.
We noticed that Google stopped to return vcard URL's on a PROPFIND request to ...
https://google.com/m8/carddav/principals/__uids__/user%40gmail.com/lists/default/
Due to this issue Thunderbird/SoGo stopped sync'ing contacts too.
Issue was reported first time 03/28/2013.
Does anyone know a workaround?
I don't think the URL you're sending the requests to is valid anymore. You should use the one, which can be discovered by sending a PROPFIND to https://www.googleapis.com/.well-known/carddav, which at this moment is:
https://www.googleapis.com/carddav/v1/principals/your#gmail.com/lists/default
Related
We are using the Google Homegraph API to implement REQUEST_SYNC functionality for our Google Home project. This has appeared te be working fine in our testing, but recently we noticed that roughly a third of requests are responded to with HTTP codes other than 200.
We have seen the following codes:
400 Bad Request
500 Internal Server Error
429 Too Many Requests
404 Not Found
429 is most likely due to some fault on our part, and we are currently looking into avoiding this. However, we are unable to determine what is causing the other codes.
In our limited ability to test, we have found that it appears to be limited to a specific user each time. Unlinking and re-linking our service seems to fix the issue (if only temporarily).
As a side note, the example here appears to contain invalid JSON, as there are quotation marks missing around agent_user_id. When testing a simple request, the omission or inclusion of the quotation marks didn't affect its success, but this may be confusing to readers.
Does anyone have advice to offer regarding these issues?
EDIT:
We are currently trying to reproduce the issues for an account by purposefully sending many REQUEST_SYNCs. This causes a number of 429 responses (and we've seen a single 500), but it has not yet caused future REQUEST_SYNCs to stop working entirely - previously we saw a user only ever receive 500 response codes until the service was relinked.
Unlinking a user did cause subsequent REQUEST_SYNCs to respond with 404, as expected. Is there a way to be notified when a user is no longer using our Google Home service so that we may stop sending them SYNC requests when they change something about their devices?
A 400 may happen if there's an issue with your server sending data, such as if your agent_user_id has not been established in the Home Graph but you're trying to call something like REQUEST_SYNC.
A 500 may happen if the data you're returning has an issue, like if it doesn't match the schema or is otherwise not formatted correctly.
A 429 may happen if you're hitting the API too often.
A 404 may happen if the URL you're requesting doesn't exist, such as if the API key is invalid or the parameters you're sending are invalid.
If you can identify reproducible cases, it would be easier to find a fix.
My weather app using the yahoo API worked fine for the last year using OAuth protocol. It suddenly stopped working working yesterday throwing this:
System.Net.WebException: The remote server returned an error: (502)
Bad Gateway.
weather.yahooapis.com also returns
Connection refused Description: Connection refused
Any idea on what the problem could be; if its on my end or an issue with yahoo?
The problem is probably on the Yahoo end.
My application broke too. I have temporarily fixed the problem by replacing weather.yahooapis.com to weather-ydn-yql.media.yahoo.com. The endpoint URL which was exposed previously is down today, I found alternative working URL through some google searches (apparently it seems they have updated their android mobile app yesterday which may have broken this, don't know guessing this based on google search results).
Anyhow, Yahoo weather developer document now recommends not to use weather.yahooapis.com and use instead YQL
You can use below URL for as per YQL recommendation instead of
Old URL
http://weather.yahooapis.com/forecastrss?w=2502265
New recommended URL
https://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid%3D2502265
Here, parameter w is WOEID.
We are implementing a Facebook application where AS3(XIFF 3.1.0 lib) is used to login to Facebook chat so that the App may send some notifications to the user's friends. At this point we come across a problem regarding a cross domain policy file required by Adobe. The thing is, when the request to get a cross domain policy file from chat.facebook.com (using
Security.loadPolicyFile("xmlsocket://chat.facebook.com:5222") ) is answered from an IP address other than 69.171.241.10 the zero byte terminating the policy file is missing in the response from the server(e.g. 173.252.107.17:5222).
According to Wireshark the flow looks like below.
Request:
<policy-file-request/>
\000
Response:
<allow-access-from domain=\"*\" to-ports=\"5222\"/>
According to the Adobe recommendation "The server must send a null byte to terminate a policy file, and may thereafter close the connection; if the server does not close the connection, Flash Player or AIR does so upon receiving the terminating null byte."
Assumption: As a result the flash player considers that no policy file is received and doesn't process xmpp login to Facebook chat.
If the assumption is correct then it looks like a Facebook bug.
Any help would be greatly appreciated,
Thanks.
This does appear to be a Facebook bug. I've verified this by performing a Wireshark link against the Openfire XMPP server (which works correctly). Have reported the bug with FB:
https://developers.facebook.com/bugs/707541335928781
Good News!!!
Facebook has fixed the bug.
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!
Ok .. I am using the Dialog JS API to send requests to people. I know this is working because
The JavaScript callback shows the request ID
On the recipient's account, the "App Requests" item on the left side bar has a count which is increasing with each and every request that gets sent
What I cannot figure out is why, although the requests are being sent and the counts are increasing, there is nothing that indicates that a request has in fact been sent.
I have checked the Notifications section and it is empty. I have also checked the following two URLs, both showing nothing:
http://www.facebook.com/reqs.php
http://www.facebook.com/reqs.php#!/?sk=apps
After hours of debugging and looking at other peoples apps, I started digging into Facebook's bug tracker and found someone else with the same problem today Apparently there are a number of "request" bugs today.
https://developers.facebook.com/bugs/237217296327314
Do you have a valid canvas url and valid secure canvas url in your facebook app settings? May be something to check as I believe it is required.