I started using the Azure Maps API on a project using Logic Apps (Azure). All of a sudden the HTTP action stopped working and I am getting a 400 BadRequest Error.
"error": {
"code": "400 BadRequest",
"message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
However, when I call the same API using Postman or my browser, it works fine.
API: https://atlas.microsoft.com/search/fuzzy/json?api-version=1.0&subscription-key=xxxxxxxxxxxxxxxxxxxxxxxxxxx&query=2 5 Donlands Ave 4 Toronto Toronto &countrySet=Ca&maxFuzzyLevel=2&limit=1
As I mentioned, this was working and all of a sudden started failing on Logic Apps without making any changes.
I exactly have the same issue.
I use address rest api to retrieve cities from postal code.
Sample :
https://atlas.microsoft.com/search/address/structured/json?subscription-key=mySubcriptionKey&api-version=1.0&postalcode=35000&countrycode=fr&limit=1
Like you, if I use the query client side, I have a 400 bad request with message :
{
"error": {
"code": "400 BadRequest",
"message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
}
}
Please note that the query is OK for google chrome, but return a 400 bad requests with Brave, Edge (chromium) and Firefox.
Note also that the sample web sdk have the same issue and is not updated.
Currently, I don't have any idea about where is the problem.
Edit : After some investigation, i'm pretty sure that it's a Microsoft issue.
So, I found a workaround.
If I try my query with Firefox, by default I have a 400 and a 200 with chrome.
I compare the header and the issue is with the accept-language.
By default, on Chrome, I Have : Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
On Firefox (Brave, Edge also maybe), I Have : Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Please note the inversion between fr-FR and fr.
If I change my Accept-Language on Firefox from fr,fr-FR to FR-fr,fr. It's working.
If I set my Accept-Language to "fr" only, I still have a 400. Work with "Fr-fr".
So after some test, my conclusion is that atlas have an issue with two letter header accept-langage.
So on my TS/JS code, just add accept-language with 4 letters to work again.
xhr.open('GET', url, true);
xhr.setRequestHeader("Accept-Language", this.acceptLanguage);
xhr.send();
My opinion is that it's a server/ atlas issue, I can't imagine this kind of code evolution from Microsoft ^^
Related
I develop an integration with Azure Ad which supports incremental synchronisations of users and groups.
It worked fine for quite a long time, but recently some (not all) of my customers started encountering one specific error.
For a request like:
GET https://graph.microsoft.com/v1.0/groups/delta?$skiptoken=<TOKEN_FROM_PREVIOUS_SYNCRHONISATION>
The API returns a response with status code 400 and body:
"error": {
"code": "BadRequest",
"message": "Resource not found for the segment 'contacts'.",
"innerError": {
"request-id": "<SOME-REQUEST-ID>",
"date": "2019-02-27T20:01:16"
}
}
I want to point out that this error occurs for some specific customers and I was not able to reproduce it on my environment.
Could someone give me a hint or two what could be causing this error?
Make sure you are using skip tokens and delta tokens correctly.
You should only have a skip token when you get the next page of a delta response.
Later when you want to get changes, you have to use a delta token.
So $deltaToken instead of $skipToken.
Like the delta link here: https://learn.microsoft.com/en-us/graph/delta-query-events?view=graph-rest-1.0#sample-third-and-final-response
I have the exact same problem when I send a request to the following endpoint
GET https://graph.microsoft.com/v1.0/groups/delta?$select=id,displayName,description&$expand=members
However, it works if I remove the "$expand=members" parameter from the URI. Could that be what's causing it in your case too?
After couple of days, my customers stopped raising the issue, so I believe the problem was temporary and on Azure side.
Failed to load resource: the server responded with a status of 403 (Forbidden)
In this subdomain-site, the static map will apear without key:
http://ag16.stewede.ch/thom.html
The same html code, but another domain:
http://praxisgemeinschaftamgleis.ch/thom.html
the map is broken and gives back the above mentioned error.
Why is that so?
Thanks, Stefan
PS: The first link works fine without a key. Now I've added one to the second link. But also with a key. It won't work! What's wrong here?
You need to use API keys.
In praxisgemeinschaftamgleis.ch the request for the map gets this error response from the API:
The Google Maps API server rejected your request. This service requires an API key.
This is new, since June 22, 2016.
See also How do I check if my domain is grandfathered?
I'm trying out the Azure Mobile App API and getting an error on making Patch calls.
GET and POST and DELETE works fine.
Here is what my url looks like:
PATCH http://mymobileappapi.azurewebsites.net/tables/Skill/c89027fa-edce-4d36-b42a-ecb0920ebab6
body:
{
"name": "Leadership SDFF"
}
I have these as headers too (as I said other http verbs work.)
ZUMO-API-VERSION 2.0.0
Content-Type Application/Json
And I get 500 error back with this in the body:
{
"error": "An item to update was not provided"
}
The same id works when I do a GET using that id...
And when I make the same call using same body with PUT i get a 404 Not found without any content in the response body.
Any ideas?
It turns out our implementation requires the content-type header value to be lower case, i.e. application/json works, whereas Application/Json doesn't. I've updated this issue to be the placeholder for the fix. As a workaround in the meantime, make the value for the content-type header lower case.
https://github.com/Azure/azure-mobile-apps-node/blob/master/src/express/middleware/parseItem.js#L27
should use req.get instead of req.headers. Keep in mind that values can also include encoding, e.g. application/json; charset=utf-8
Here is link to the issue:
https://github.com/Azure/azure-mobile-apps-node/issues/368
My code calls the OneNote API to resolve a SharePoint Online site URL to a SiteCollectionId and SiteId. We get a bearer token, set the HTTP auth header and issue a GET request to:
https://www.onenote.com/api/v1.0/myorganization/sitecollections/FromUrl(url='https://mytenantxyz.sharepoint.com/sites/copynotesite')
For approx a week, it has been returning the expected response, similar to:
{
"#odata.context": "https://www.onenote.com:576/api/v1.0/$metadata#Microsoft.OneNote.Api.SiteMetadata",
"siteCollectionId": "111e03ac-468c-4a28-9aab-543098ef49bb",
"siteId": "555d72a0-f82f-4e4c-ae8a-17ef0ea04f32"
}
However, today it has decided to return the following in approx 9 out of 10 requests:
{
error": {
"code" : “20158”,
"message": "Unable to get SiteMetadta for the url specified in the request.",
"#api.url": "http://aka.ms/onenote-errors#C20158"
}
}
The Microsoft docs (link) explain error 20158 as:
"Unable to get metadata for the site URL specified in the request. Check the format of the supplied URL. Supported formats include https://domain.sharepoint.com/site-a and https://domain.com/sites/site-a. (SharePoint support is in Preview.)"
I was unaware that this was in preview any more (I thought it was GA), but anyway it doesn't explain why it intermittently works for exactly the same input (same URL and bearer token).
Could it just be a bug in the OneNote API or SharePoint API that it must call under the covers?
Please refer to the blog - http://blogs.msdn.com/b/onenotedev/archive/2015/06/11/and-sharepoint-makes-three.aspx
We added the FromUrl method so you can pass in an absolute site URL and get the site collection and site IDs. You should make this call only when needed, and then store the values (site collection and site IDs) for future use in your requests to the OneNote API.
this however does not answer intermittency. Please share the X-correlationId header with us for a failing request so that we can help further.
Using a browser REST client to POST to the activity stream at e.g.
https://connectionsww.demos.ibm.com/connections/opensocial/basic/rest/activitystreams/#me/#all
...with the settings prescribed in IBM Connections OpenSocial API > POSTing new events
...results in the following response:
<error xmlns="http://www.ibm.com/xmlns/prod/sn">
<code>403</code>
<message>You are not authorized to perform the requested action.</message>
<trace></trace>
</error>
What am I missing?
This same approach works nicely on IBM Connections 4.0.
Which setting needs 'switching on'?
Try a URL like this... https://sbtdev.swg.usma.ibm.com:444/connections/opensocial/basic/rest/activitystreams/#me/#all
I added the Basic/Rest component, and it worked for me.
1 - Added URL https://sbtdev.swg.usma.ibm.com:444/connections/opensocial/basic/rest/activitystreams/#me/#all
2 - Changed Method to Post
3 - Added Content-Type: application/json
4 - Authentication -> Basic
5 - Logged IN
6 - Posted
Same thing here: 403 when I make an AJAX call to an IBM Connections 6.0 REST API url. Same error in Chrome, Firefox and IE11. When I open the same URL in a separate browser tab, everything works fine.
Comparing the http headers of both calls, and fiddling with Postman, the diference is the presence and value of the atribute Origin.
Seems that Connections allows calls from its own server. For example, when: Origin: connections.mycompany.com.
It also allows calls when Origin is not defined, which happens when the url is called from a separate browser tab.
There is a doc at IBMs Support site that confirms this - http://www-01.ibm.com/support/docview.wss?uid=swg21999210. It also suggests a workaround that did the job for me: unsetting the Origin attribute in the IBM HTTP Server that is in front of your Connections instance. Add the lines below to the httpd.conf file:
Header unset Origin
RequestHeader unset Origin