The Bing Web Search API worked last week and at some point this week, it has been returning 403 errors. I don't know if anyone else has been encountering similar problems?
To replicate this, simply signup here with a bing account and you should get 5000 free queries per month. Below is a snippet of code (I believe I'm properly authenticated since putting in improper credentials fails gives a 401, rather than 403 error).
import requests
user = '...'
key = '...'
# 403 error
requests.get('https://api.datamarket.azure.com/Bing/Search/Web?Query=%27Xbox%27&$format=json', auth=(user, key))
# 401 error
requests.get('https://api.datamarket.azure.com/Bing/Search/Web?Query=%27Xbox%27&$format=json', auth=('a', 'b'))
Is anyone else getting this?
403 is the Forbidden status code. Your subscription probably expired or you exhausted your query limit.
Server errors are always in the 500-599 range. Errors in the 400-499 range are always client errors. If you repeatedly receive 500 errors, you should check Azure's status page to ensure there isn't a problem.
As a rule, you shouldn't assume that a major service like Bing Search is down and no-one noticed for days. It's far more likely that there is a problem with your account or your code, especially if you receive client error codes.
Related
I was following the tutorial
https://codelabs.developers.google.com/add-to-wallet-web for building a generic pass over the api.
using https://github.com/google-pay/wallet-web-codelab as repo.
after some struggling with the 7 days test account (if someone gets 403 unauthorized requests check that you use the same iam email for the test account on the register page)
okay, all works well, i get the stored wallet object back but when i try to reach the URL
Test-URL with JWT there is always an undefined error coming back and I have no clue how to debug or check what is the problem.
anyone who could give hints on what is going wrong here?
thanks!
As the subject line states, all API calls for the past 6 days have resulted in Error 400 ThrottleUser responses. Tried a new api key; pox, json and service connections.
Is this happening to everyone? Does anyone know how to tell them it is not working?
Support can be requested here: https://www.bing.com/webmaster/support
as suggested here: https://social.msdn.microsoft.com/Forums/en-US/f24edc35-5aab-445a-91b8-73a1982019d7/webmaster-api?forum=whatforum
I consistently get this response
{ error: { status: 500, message: 'Server error.' } }
when I try to retrieve all playlists for my user using this endpoint
GET https://api.spotify.com/v1/users/{user_id}/playlist
I am doing this repeatedly as a test case while I develop the plumbing for my Spotify web api application.
Sometimes it fails when I start at offset 0. Sometimes it succeeds at offset 0 (and offset 50, 100, 150, etc.) and fails later. I have about 900 playlists.
It fails whether I get 20 playlists at a time or the maximum of 50.
I see nothing unusual in the response headers.
Is this a bug on the Spotify's end? I assume since I'm getting status 500 that this is not related to hitting a request rate limit of some kind, or some error in my request.
I would appreciate any insight anyone has to offer.
Responses with status code 500 from the /v1/users/{user_id}/playlists/ endpoint can be caused by a number of reasons, none of which is your application's fault. There are cases where a user's list of playlists (or an individual playlist) cause temporary issues in Spotify's backend. This occurs more often if the list of playlists have a lot of revisions, e.g. the user has an unusually large amount of playlists and have removed, added and moved them around a lot. We're working on resolving this but meanwhile we ask you to try again.
This isn't related to any of the query parameters sent in the request, it's simply an intermittent error.
Is this a bug on the Spotify's end? I assume since I'm getting status 500 that this is not related to hitting a request rate limit of some kind, or some error in my request.
Spotify's Web API return a response with status code 429 if the request has been rate limited. A list of which status codes are returned from the Web API can be found in the User Guide.
This endpoint on Spotify's Web Api throws a 500 error for the username "spotify":
GET https://api.spotify.com/v1/users/{user_id}/playlists
Is this intentional on Spotify's end? Does Spotify not wants developers to access its playlists.
Note - All other usernames work fine
A 500 error should always be treated as being unintentional. If the server side wants to limit access a response code in the 400 range should be used instead, like 403 or possibly 401. It is likely that there are so many different public playlists for the Spotify account that one of them has triggered a bug. If for some reason the error code 500 is intentional, it is still a bug, but in the API, which should be fixed.
I work at Spotify, but don't have direct access to this system. I will let people know.
My server returns a 403 forbidden error when a user tries to access a resource that they do not have access to. Along with the header the server also writes a small message describing the error.
In Firefox the error message gets displayed nicely and the user knows what's going on.
In Internet Explorer the message is hidden and replaced with the 403 Forbidden standard error page.
Are there any specific rules that allow me to display an error message across all browsers while still setting the status to 403 Forbidden?
Here is the RFC info on this status:
The server understood the request, but
is refusing to fulfill it.
Authorization will not help and the
request SHOULD NOT be repeated. If the
request method was not HEAD and the
server wishes to make public why the
request has not been fulfilled, it
SHOULD describe the reason for the
refusal in the entity. If the server
does not wish to make this information
available to the client, the status
code 404 (Not Found) can be used
instead.
It seems like I should be setting a message but IE just won't display it.
Try making your 403 page larger (i.e. more bytes). Some browsers assume that a short error page is the default page from the web server and decide to show their own, presumably more helpful text.
More info.
The implementation of error handling is browser dependent. In HTTP if you are just going to return a 403 error then you have to rely on the user agent (the technical name for the browser, the recipient of your error message may not be a browser) to handle out how it sees fit.
If you don't like how the browsers are handling 403 errors and want to ensure a consistent user experience across all browsers then redirect the user to your own 'permission denied' page. You can build a page that can explain to them why permission was denied and what they might be able to do about it. And it will be consistent for any browser.