The Lyft API recently stopped adding
access-control-allow-origin:*
to the ETA and cost estimate endpoints, so it is no longer possible to get that information in the browser because of CORS restrictions. Of course, I can just grab the data on my own server, but it seems unnecessary to create an extra hop for the data. Has anyone else experienced this? Do you know if Lyft changed their policy, or was this just an accident?
https://developer.lyft.com/v1/reference#availability-driver-eta
https://developer.lyft.com/v1/reference#availability-ride-estimates
Related
I have an application which writes lots (millions) of calendar entries to mailboxes for large organisations. Occasionally, Office 365 EWS API will accept a batch of entries, return success (not error) codes, and the entries fail to make into mailboxes.
Microsoft support don't (appear to) have a public-facing API support team so the usual Microsoft support routes just say either "third-party application" or "we don't have a support team you can speak to" ... so I'm a bit stuck. This does not appear to be a failure of the app, as I can see from the trace that it writes successfully and is given a change key back. And this only happens over a short period of time (say, all writes in a 30 min window have this problem).
I'm a bit stuck as to where to go here, as there's no error, just occasional and undesirable behaviour. It could even not be the API that's at fault, and could be just a sync error between EWS and mailbox stores. But, as it's Office 365, I can't see this.
Application is .Net 3.5 if it helps; very stable installs, runs fine for years, just occasionally has this problem... with just one customer...
I'm a bit stuck as to where to go here, as there's no error, just occasional and undesirable behaviour. It could even not be the API that's at fault, and could be just a sync error between EWS and mailbox stores. But, as it's Office 365, I can't see this.
EWS is just an API to access the Mail Store there is no sync involved and no cache, if your getting an ItemId returned then it must at some point have been written to the Exchange Store. DAG's https://learn.microsoft.com/en-us/exchange/high-availability/database-availability-groups/database-availability-groups?view=exchserver-2019#:~:text=A%20DAG%20is%20a%20group,affect%20individual%20servers%20or%20databases.&text=For%20example%2C%20you%20can't,servers%20in%20the%20same%20DAG. are Exchanges way of ensuring redundancy.
How are you determining that the appointments aren't in the Mailbox (or haven't been deleted or modified by another mail client). Most likely it will be another mail client (eg the IOS client has been cause of many issue of the past years). I would suggest calendar logging or auditing maybe be useful to see what might be happening if you can reproduce the issue.
when I to test my Website (it is outside from my computer) with the tool lighthouse on Chrome, comes this report;
All sites should be protected with HTTPS, even ones that don't handle sensitive data. HTTPS prevents intruders from tampering with or passively listening in on the communications between your app and your users and is a prerequisite for HTTP/2 and many new web platform APIs. Learn more.
What I don't Understand why to come this, I have my Website with https — the report to say that my images and URL do not use HTTPS.
Screenshot from this warning;
I have to test my Website for https mistake with https://www.whynopadlock.com/f73e9366-da69-4ebf-a73f-6ceff2161cd6
Screenshot from it,
How to see, I have all gut, but the Tool lighthouse every time give me a similar result...
Can Please anyone help me with this problem, Thanks!
the transfer protocol your site current uses is HTTP/1.1
which has been the de-facto standard since 1997. In an effort to ensure a secure encrypted connection between browsers and websites, giants like Google and Let's Encrypt have been pushing sites to use HTTPS.
Google came up with a new way networking protocol SPDY which is termed a precursor to HTTP/2 which rolled out in 2015. Google suggests websites to use HTTP/2 as the new de-facto standard protocol which brings in multiplexing, header compression, binary transfer of data and much more.
The message that you have recieved would go away once you enable HTTP/2 on your server
As you haven't mentioned your webserver, here's how you enable it for Nginx and Apache
We have a crawling engine that we are trialling on Google Kubernetes Engine.
It appears that we are severely network bound when it comes to making request outside the google network.
We have been in-touch with an architect at google, who though that perhaps there was some rate-limiting being applied inside the google data centre. He mentioned that I should raise a support ticket with Google to investigate. Raising a ticket involves subscribing to a support plan (which I am not ready to do until the network issues are addressed) [a bit of a catch-22].
Looking at the network documentation: https://cloud.google.com/network-tiers/?hl=en_US it seems that rates might be severely limited. I'm not sure that I'm reading this right, but are we saying 6Mbps network?
I'm reaching out to the community / Google to see is what we are seeing is expected, if there is any rate limiting and what options there are to increase raw throughput?
You can raise a ticket with Google using the public issue tracker free of charge. In this case, since it's possibly an issue on the Cloud side of things, raising a ticket in this manner will get a Google Engineer looking into this.
We have received mail from Google mentioned that "It appears that your project is performing intrusion attempts against a third-party. We will suspend your project in 3 days unless you correct the problem by ensuring your project traffic directed at third-parties is expected, and that your project has not been compromised."
I have cross checked all my access/error log, Firewall ports,DDoS log, etc. I've not found any problem from server end. Has anyone faced same issue?. It's critical for my client project.pls help
We are using the google-api-client gem in our Ruby on Rails project to access the Google Drive API methods and everything has been working great. However, we are sometimes receiving the following error response from the API when calling the drive.files.update or drive.files.insert methods:
{"code"=>500, "message"=>"Unable to read application configuration information"}
This error is not documented in the list of possible errors from the SDK, so I am not sure how I should go about it. Could you please help?
Thank you!
If this error is transient, the best way is to have a retry strategy when that happens (simply retry the request 2 or 3 times before giving up).
It seems like some concurrency issue on the Drive side where a request to read your application's configuration times out. By experience with Google APIs - and web APIs in general - I can tell you that, even though the team will try to fix/improve these (btw I will repport the bug so they can investigate) errors like that will always happen once in a while even with a very low occurrence as concurrency, timeout and reliability issues on distributed, web-scale systems are extremely hard to resolve. The best to have fail-proof code on your side is to retry a few times on every single 500 and 503 errors from external web APIs.
If you really have time on your hands you could even implement an exponential backoff strategy where the time between each of your retries increases each time as described in our documentation.