I want to love the v3 API. Unfortunately, when making the seemingly simple call:
service.executeQuery("select * from TimeActivity");
I get the crushing reply of:
<Error code="6002">
<Message>message=Timeout occurred while proxying request; errorCode=006002; statusCode=504</Message>
</Error>
What kind of problem could cause this?
Typically a 504 error code indicates there is a dependency timeout. It is clear that the server you are contacting is responsive, as you are receiving the response.
This kind of error is common if there is any kind of fault in the back end of the server or some service they rely on has gone down. You may want to contact the system administrator or responsible support team to ask about this, as it's likely affecting anyone accessing the same service as you.
It looks like something is wrong with my account. All TimeActivity queries fail in the API explorer. To Intuit support I go!
Related
I'm working on a music media library that allows users to share music in their library but only if they marked as shareable.
In the backend I'm checking if the music file is shareable like so
if(file.shareable) share
else throw 500 or 400?
To me this is a 400 bad request because the the user is trying to do something that the business does not allow.
Is this the corret way?
4xx indicates a bad request -- i.e. "don't try re-requesting".
5xx indicates that the server had a problem, i.e. "give us a minute, and try again later."
So if it's business logic, that would be a 400 level error, i.e. don't re-request.
You should use 4xx codes for any client error that prevents the server from returning a useful response. This includes requests that violates business rules. The point is to indicate to the client that the request is invalid, and potentially include steps the client can take to fix the situation.
Use 5xx codes if the server encounters an internal problem that prevents it from doing its work. Maybe the database or a necessary external service is down, or there's a programming error somewhere. Maybe the server is just too busy right now. Not much the client can do to fix that other than try again later.
Basically:
4xx: Your fault.
5xx: My fault.
We have a Client Toolkit provided by our partner that allows us to access their web services. It started giving errors yesterday on any call and initially their support wanted us to provide a Fiddler log. I tried to do so, however there was no activity shown in Fiddler when the call was made.
From this I would have assumed that the error would have to have occurred before an actual web request was sent out. However, the issue turned out to be an update they did that requires an SSL connection. They rolled back the change but advised us to update our calls to use https so they can re-implement their update.
So if the change was on their end, that means that communications obviously were going on with their server. Why wouldn't that have shown up in Fiddler? Are there scenarios where communications occur but a request isn't fully created or something like that? I just assumed that if there was any communication whatsoever that "something" would show up in Fiddler.
I have a RESTful service that throws a 500 INTERNAL SERVER ERROR status upon an internal failure for a number of reasons: DB errors upon connectivity or field size, code bugs, or issues with a managed code call. The resulting unhandled exception is reported back by IIS as a 500. Is this an appropriate use of 500? It could imply "retry request" according to MSDN Common REST API Error Codes. The proper API error code I am seeking is something like "### Server will NEVER process this request until a code change is made, do not resend or you will be looping forever and DOSing my server". Would a 400 Bad Request be more appropriate? It seems as if this is indicating a malformed request syntax itself, not that the service choked.
Furthermore, what should a client do when it encounters such an error? The server does not want another RESTful operation exactly like the previous one. The user may have spent some time doing data entry. Now we have to talk them off the ledge. Perhaps they can fix it on their own and that is the best practice? What are some similar experiences developers have had and how was it solved? Thanks.
4xx errors are "something is wrong with the client, they're sending the wrong stuff".
5xx errors are "something is wrong with the server, sorry it's out sick today."
Which basically means there's nothing the client can imply from a 5xx error. It could be permanent, it could be transient, the client doesn't know.
IIS sends a 500 error because IT doesn't know what happened. If your app is blindly throwing exceptions up to the web tier, there's not much more it can do or say about it.
If the server logic somehow actually KNOWS what's wrong, and WHEN it might be fixed, it can send a 503 error, telling the client it's unavailable and a Retry-After header telling the client when it will be back.
As for a client behavior, it's sort of dependent on the clients history with the service. Maybe the service intermittently fails with 500 errors, and another request will just work. This could happen, say, if you have a set of load balanced servers. The first server they hit is sick, but perhaps not sick enough that the load balancer has taken it out of rotation yet. So, another server may be just fine -- in that case the client could just retry and see what happens.
But in the end, it's up to the client as to what to do. It could try a simple back off algorithm. Retry once or twice. Retry once immediately, then again in 10s.
Or it could just push the 500 error back to the user with a polite message "tough luck".
Only the client use cases and requirements can really dictate what it's behavior should be when the server is dead.
At the client side, we have to assume that the web-service is good, and that this either a malformed request (i.e. the user has keyed in something in-appropriate), or a network error of some kind. The method I used is to use an alert box, requesting the user to refresh the screen (F5), and try again with proper input. You may want to add "in case error persists, contact ...".
I have been getting this error message the past 36 hours. Facebook support has not been any help at all when it comes to resolving this issue. I've cleared my cookies and cache multiple times. I've tried from multiple machines as well as my phone. Still no luck on logging in. Is it an error on my part or are they doing maintenance? Please assist, I did not want to have to post here but I have no more options...
The website cannot display the page
HTTP 500
Most likely causes:
•The website is under maintenance.
•The website has a programming error.
What you can try:
Refresh the page.
Go back to the previous page.
More information
This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying.
For more information about HTTP errors, see Help.
It's probably something on their end. Responses with a 5xx status code are used when the server is aware it has erred in some way. More specifically, the 500 error has the following definition:
500 Internal Server Error:
The server encountered an unexpected condition which prevented it from
fulfilling the request.
If the response had a 4xx status code, then the fault would lie on you. For example, if you made a request to a resource that doesn't exist, then you'd get a 404 response. As it stands now, something is wrong with their server.
Had the same problem. It appeared to be caused by this:
https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.1#asking-for-permissions
Apps that ask for more than public_profile, email and user_friends must be reviewed by Facebook before they can be made available to the general public.
We were asking for more than the default, so I presume the 500 is caused by this lack of review.
It appears it can also happen if you haven't made your App public and try to login to it as anyone but you (the account that created the App).
Currently, we are using GetHttpRequestData().headers to get real IP address of User. However, we are facing following issue. when we try to call SOAP web service request, we receive following error Premature end of file. I already searched the web and found out that there is bug in ColdFusion 8.0.
I don't know if this bug is resolved yet.
Is there any alternate solution?
Please help me.
thanks
Is the SOAP request coming in to ColdFusion from a client and that is where you are getting the error or is a user hitting a coldfusion page that is then making a soap request to some other service and that is generating the error?
We had the exact same issue. I don't know if you've found a solution yet but the workaround I found is using getPageContext().getRequest().getHeader("name of header here") to retrieve the request header I'm looking for. This doesn't break to SOAP calls like getHttpRequestData.