Don't serialize server errors to client. #1126
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Server side errors may contain just about anything, such as e.g. secrets, and, therefore, it seems like a bad idea to unconditionally send these back to the client. In general, there is nothing a client can do about an internal server error even if the specific internal error message is known. The server developer can already see the error in server logs so there isn't really any loss of information.
If the current behavior is actually desired it can be achieved by an outer
try-catch
in the handler function. (Of course, an outertry-catch
can also be used to make sure that a server side error never ends up at the client, but it is better to be safe by default.)Concrete example with a server that itself sends a request to another upstream server that requires authentication:
This is the output from curl: