I wrote a Node service that takes parameters from a client and puts them into a SOAP request to another (3rd party) service. Lately, when a request is made to my service, the initial response is a 502 Bad Gateway error with a generic HTML block titled "Server Error" (see image). When I submit the same request a second time, the 3rd party responds with a 500 Internal Server error and a message indicating that a request has already been issued for that transaction.
Obviously the initial request made it to the 3rd party somehow, but they say that the 502 error isn't theirs and isn't logged in their system as ever having occurred.
What I'm trying to find out is if the error is somehow coming from my service because of Docker or Azure (or something else I'm not thinking of). The error is so generic that research hasn't yielded anything useful on it. Has anyone encountered this or know what it is?
It turns out that this was an error being thrown by Azure (or so we think) as the result of some faulty error-handling. Part of the response was being parsed incorrectly, which caused the app to stall. It still doesn't explain how the data still got to the other side while this was happening (or why it hit the catch block at all when there was no error in the processing), but if you see a server error returned with this HTML block, check your error-handling code and investigate Azure!
Related
Why is error 410 considered a user error (4xx) and not a redirect (3xx) or a server error (5xx)?
I request a payload from a server, and the server returns a link. I copy the link and the link gives 410? It isn't my fault to verify the link actually exists on their server. But at the same time, from the server's point of view the error originated from me, as I accessed something that doesn't exist, similar to 404 where I access something that was never there.
Can anyone help me understand the decision behind this?
Code 410
"410 Gone" client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.
If you don't know whether this condition is temporary or permanent, a 404 status code should be used instead.
Why is error 410 a user error and not a server error?
It's not a "user" error, it's a client error; but yeah, that's a lousy label. The labels reflect the client-server architectural constraint, but it might be better to use labels that point more directly at the contents of the request, rather than the client (or the user).
In practice, it's a client error for the same reason that 404 is a client error; it is specifically calling attention to the target resource of the HTTP request.
In the context of the web, it does make some (imperfect) sense - the client followed a broken link (which could be a consequence of the server's current representations, but might also come from following links in stale representations, following stale bookmarks, a spelling error in a representation provided by a different server, etc).
It's not a question of fault, it just means that the request should not be considered to ever work in the future (it shouldn't be retried). Whereas a server error (like a 5xx error) could be retried periodically and should eventually work sometime in the future since the request itself is considered valid.
We have a route in our API which (when called) hits another 3rd party API.
e.g.
HTTP-GET /account/1
this returns some data from our database AND from .. say .. a 3rd party api like Auth0/Okta/SalesForce/whatever.
Now, if this 3rd party api call fails for any reason (fails == 4**, 5** or even a 200 OK but the content is some error message) then what error status code should I pass back to the client calling my API?
Initially I was thinking an HTTP-500-Server-Error but ... I'm not so sure now because I can prevent this error from occurring in the server if I return a nice error message back to the client. So then I thought, return an HTTP-200-OK which contains some key/value of the downstream issue/error ... but is this really OK (pun intended). To me, HTTP-200-OK is like the answer returned is really ok.
So i'm not sure what people do in this scenario.
I feel like an HTTP-500 is for errors that occur but haven't really been handled and/or accounted for.
Now, if this 3rd party api call fails for any reason (fails == 4**, 5** or even a 200 OK but the content is some error message) then what error status code should I pass back to the client calling my API?
APIs should be designed from the consumer's perspective. In most of situations, the API consumer wont't care if the request is fulfilled by the server they are firing a request to or by a downstream server.
If the request to the downstream server prevents your server from fulfilling the client request, you could go for 500 or 503. Alternatively you could return some cached data (if you have any) and return a 2xx status code.
Hi I have a REST web service.
The service method throws java.lang.Exception but the client always receive Http Code 200 which is success.
Shouldn't the rest service return other code than 200?
Probably yes. 200 OK would imply that the request would have succeeded. It sounds like this was not a success so it should have been something else.
If your code is throwing an Exception, it's supposed to be broken and not delivering whatever your request wanted. That indeed should not return a "200 OK" response.
Here's a few things to do:
Don't throw java.lang.Exception. Try to be more specific about the exceptions on your code so it's easier to identify the problem when something crashes.
Determine WHAT is happening that is throwing that exception.
In most cases, send a 400 Bad Request when something is wrong and the client is guilt for that. If it's a server-side problem, it's usually a 500 Internal Server Error response. Do a little research on HTTP codes here.
Make sure to document any rules that need to be followed so this problem don't occur in the future.
I have seen people using the HTTP code 500 as a generic error code for all kind of error cases (server errors, http errors, code exceptions, expected record not found in DB, time-out exceptions etc). However I have also read and heard that this code 500 should only be used in case of errors originating from the application server (JBoss in my case), and NOT application itself i.e. not for code-exceptions or invalid passwords or DB-record-not-found cases. So, when should we return HTTP Status Code 500 from a REST service method?
As described in the HTTP spec:
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.
Original: https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.6
Note that from the protocol point of view, it doesn't matter whether it's the application server or something running inside the application server.
I have a ASP.NET web application that implements url rewrite throught an Http Module. Each rewrite rule are loaded from a database table.
After I added a new rule I got the following error:
Value does not fall within the expected range.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: Value does not fall within the expected range.
I don't find anyting in application logs.
In this case, after a long investigation I found the character
\n
after redirection url name.
When http module send redirect to IIS, all went Ok, but during request processing IIS itself got the error above.
I think that's a very strange error, and I spent lot of time to detect, so I think to share solution (of course it's all my fault!).