I have an application that reads users mail messages. I made the same call multiple times in a row. The middle attempt i received an error indicated that the requested user was invalid. I know this to not be true since i had requests before and after this request pass with the same parameters.
{"error": {"code": "ErrorInvalidUser", "message": "The requested user 'scrubbed' is invalid.", "innerError": {"date": "2020-10-05T14:42:17", "request-id": "30ede436-594b-4146-b06f-42ceff3201db", "client-request-id": "30ede436-594b-4146-b06f-42ceff3201db"}}}
I am wondering what conditions can cause this error. Would an expired oauth token cause this error. Or does this error really reflect that this user no longer exists? (in this case, that would not be an accurate error message).
I did check this page to see if this error is mentioned, but nothing is listed:
https://learn.microsoft.com/en-us/graph/errors
I'm facing a strange issue with direction service in azure maps.
When I make this request with car in travel mode :
https://atlas.microsoft.com/route/directions/json?subscription-key={my-api-key}&api-version=1.0&query=48.81532,2.34954:52.31281,4.94103&language=fr-FR&computeTravelTimeFor=all&travelMode=car&arriveAt=2018-10-30T09:50:00-00:00
I got a good response with a proper json, but I make the same request with bicycle travel mode :
https://atlas.microsoft.com/route/directions/json?subscription-key={my-api-key}&api-version=1.0&query=48.81532,2.34954:52.31281,4.94103&language=fr-FR&computeTravelTimeFor=all&travelMode=bicycle&arriveAt=2018-10-30T09:50:00-00:00
I get the following error :
{ "error": {
"code": "400 BadRequest",
"message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive." } }
I can't figure out what makes this error
I changed the arriveAt time to 2018-10-31T09:50:00-00:00 and it works. Perhaps biking takes so long that it's impossible to arrive at the destination by the specified arriveAt time.
For example such code:
os.Stderr.WriteString(rec.(string))
But this will not show as an error:
I know that I can panic after logging and catch it on API Gateway (against sending stacktrace to the client) - no other ways? Documentation is not mention anything like that.
It seems not possible. I assume, you're looking at the metrics in Amazon CloudWatch
AWS Lambda automatically monitors functions on your behalf, reporting
metrics through Amazon CloudWatch. These metrics include total
invocations, errors, duration, throttles, DLQ errors and Iterator age
for stream-based invocations.
https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-metrics.html
Now, let's see how do they define errors
Metric "Errors" measures the number of invocations that failed due to errors in the
function (response code 4XX).
So, if you want to see the errors on that graph, you have to respond with the proper codes. If you're concerned about exposing the error stacktrace, here is a good read Error handling with API Gateway and Go Lambda functions. The basic idea there is about creating a custom lambdaError type, meant to be used by a Lambda handler function to wrap errors before returning them. This custom error message
{
"code": "TASK_NOT_FOUND",
"public_message": "Task not found",
"private_message": "unknown task: foo-bar"
}
will be wrapped in a standard one
{
"errorMessage": "{\"code\":\"TASK_NOT_FOUND\",\"public_message\":\"Task not found\",\"private_message\":\"unknown task: foo-bar\"}",
"errorType": "lambdaError"
}
and later on mapped in API Gateway, so, the end client will see only the public message
{
"code": "TASK_NOT_FOUND",
"message": "Task not found"
}
I'm trying to use the "whisk.system/messaging" and trying to use the method messageHubProduce.
I created a bind to this package, and tried to use a simple call with postman.
Using the documentation, I created a simple json and did a call, but the method is really unstable. The same call sometimes return as a success, sometimes returns a timeout and sometimes as a "No brokers available".
I now the implementation of this code is on python. Have anyone with the same symptoms I getting?
This is the message I'm sending.
{
"topic": "mytopic",
"value": "MyMessage",
"blocking": false
}
These are the results for the same call
messageHubProduce 446d59eb816b4b34a52374a6a24f3efe
{ "error": "The action exceeded its time limits of 60000 milliseconds." }
messageHubProduce 4213b6a495bc4c5aa7af9e299ddd8fcd
{ "success": true }
After working closely with the Message Hub team, we have deployed an updated messageHubProduce action which should address your stability and performance issues.
Additionally, to provide real-time feedback please feel free to join us on Slack: https://openwhisk.incubator.apache.org/slack.html
It appears that when you make an XMLHttpRequest from a script in a browser, if the browser is set to work offline or if the network cable is pulled out, the request completes with an error and with status = 0. 0 is not listed among permissible HTTP status codes.
What does a status code of 0 mean? Does it mean the same thing across all browsers, and for all HTTP client utilities? Is it part of the HTTP spec or is it part of some other protocol spec? It seems to mean that the HTTP request could not be made at all, perhaps because the server address could not be resolved.
What error message is appropriate to show the user? "Either you are not connected to the internet, or the website is encountering problems, or there might be a typing error in the address"?
I should add to this that I see the behavior in FireFox when set to "Work Offline", but not in Microsoft Internet Explorer when set to "Work Offline". In IE, the user gets a dialog giving the option to go online. FireFox does not notify the user before returning the error.
I am asking this in response to a request to "show a better error message". What Internet Explorer does is good. It tells the user what is causing the problem and gives them the option to fix it. In order to give an equivalent UX with FireFox I need to infer the cause of the problem and inform the user. So what in total can I infer from Status 0? Does it have a universal meaning or does it tell me nothing?
Short Answer
It's not a HTTP response code, but it is documented by WhatWG as a valid value for the status attribute of an XMLHttpRequest or a Fetch response.
Broadly speaking, it is a default value used when there is no real HTTP status code to report and/or an error occurred sending the request or receiving the response. Possible scenarios where this is the case include, but are not limited to:
The request hasn't yet been sent, or was aborted.
The browser is still waiting to receive the response status and headers.
The connection dropped during the request.
The request timed out.
The request encountered an infinite redirect loop.
The browser knows the response status, but you're not allowed to access it due to security restrictions related to the Same-origin Policy.
Long Answer
First, to reiterate: 0 is not a HTTP status code. There's a complete list of them in RFC 7231 Section 6.1, that doesn't include 0, and the intro to section 6 states clearly that
The status-code element is a three-digit integer code
which 0 is not.
However, 0 as a value of the .status attribute of an XMLHttpRequest object is documented, although it's a little tricky to track down all the relevant details. We begin at https://xhr.spec.whatwg.org/#the-status-attribute, documenting the .status attribute, which simply states:
The status attribute must return the response’s status.
That may sound vacuous and tautological, but in reality there is information here! Remember that this documentation is talking here about the .response attribute of an XMLHttpRequest, not a response, so this tells us that the definition of the status on an XHR object is deferred to the definition of a response's status in the Fetch spec.
But what response object? What if we haven't actually received a response yet? The inline link on the word "response" takes us to https://xhr.spec.whatwg.org/#response, which explains:
An XMLHttpRequest has an associated response. Unless stated otherwise it is a network error.
So the response whose status we're getting is by default a network error. And by searching for everywhere the phrase "set response to" is used in the XHR spec, we can see that it's set in five places:
To a network error, when:
the open() method is called, or
the response's body's stream is errored (see the algorithm described in the docs for the send() method)
the timed out flag is set, causing the request error steps to run
the abort() method is called, causing the request error steps to run
To the response produced by sending the request using Fetch, by way of either the Fetch process response task (if the XHR request is asychronous) or the Fetch process response end-of-body task (if the XHR request is synchronous).
Looking in the Fetch standard, we can see that:
A network error is a response whose status is always 0
so we can immediately tell that we'll see a status of 0 on an XHR object in any of the cases where the XHR spec says the response should be set to a network error. (Interestingly, this includes the case where the body's stream gets "errored", which the Fetch spec tells us can happen during parsing the body after having received the status - so in theory I suppose it is possible for an XHR object to have its status set to 200, then encounter an out-of-memory error or something while receiving the body and so change its status back to 0.)
We also note in the Fetch standard that a couple of other response types exist whose status is defined to be 0, whose existence relates to cross-origin requests and the same-origin policy:
An opaque filtered response is a filtered response whose ... status is 0...
An opaque-redirect filtered response is a filtered response whose ... status is 0...
(various other details about these two response types omitted).
But beyond these, there are also many cases where the Fetch algorithm (rather than the XHR spec, which we've already looked at) calls for the browser to return a network error! Indeed, the phrase "return a network error" appears 40 times in the Fetch standard. I will not try to list all 40 here, but I note that they include:
The case where the request's scheme is unrecognised (e.g. trying to send a request to madeupscheme://foobar.com)
The wonderfully vague instruction "When in doubt, return a network error." in the algorithms for handling ftp:// and file:// URLs
Infinite redirects: "If request’s redirect count is twenty, return a network error."
A bunch of CORS-related issues, such as "If httpRequest’s response tainting is not "cors" and the cross-origin resource policy check with request and response returns blocked, then return a network error."
Connection failures: "If connection is failure, return a network error."
In other words: whenever something goes wrong other than getting a real HTTP error status code like a 500 or 400 from the server, you end up with a status attribute of 0 on your XHR object or Fetch response object in the browser. The number of possible specific causes enumerated in spec is vast.
Finally: if you're interested in the history of the spec for some reason, note that this answer was completely rewritten in 2020, and that you may be interested in the previous revision of this answer, which parsed essentially the same conclusions out of the older (and much simpler) W3 spec for XHR, before these were replaced by the more modern and more complicated WhatWG specs this answers refers to.
status 0 appear when an ajax call was cancelled before getting the response by refreshing the page or requesting a URL that is unreachable.
this status is not documented but exist over ajax and makeRequest call's from gadget.io.
Know it's an old post. But these issues still exist.
Here are some of my findings on the subject, grossly explained.
"Status" 0 means one of 3 things, as per the XMLHttpRequest spec:
dns name resolution failed (that's for instance when network plug is pulled out)
server did not answer (a.k.a. unreachable or unresponding)
request was aborted because of a CORS issue (abortion is performed by the user-agent and follows a failing OPTIONS pre-flight).
If you want to go further, dive deep into the inners of XMLHttpRequest. I suggest reading the ready-state update sequence ([0,1,2,3,4] is the normal sequence, [0,1,4] corresponds to status 0, [0,1,2,4] means no content sent which may be an error or not). You may also want to attach listeners to the xhr (onreadystatechange, onabort, onerror, ontimeout) to figure out details.
From the spec (XHR Living spec):
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
from documentation http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute
means a request was cancelled before going anywhere
Since iOS 9, you need to add "App Transport Security Settings" to your info.plist file and allow "Allow Arbitrary Loads" before making request to non-secure HTTP web service. I had this issue in one of my app.
Yes, some how the ajax call aborted. The cause may be following.
Before completion of ajax request, user navigated to other page.
Ajax request have timeout.
Server is not able to return any response.