New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suppress statusDebugMessage when Exception thrown in REST api #1623

Closed
SingingBush opened this Issue Nov 17, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@SingingBush

SingingBush commented Nov 17, 2016

if an exception is thrown in the rest interface the following Json is returned:

{
    "statusMessage": "An error message, hopefully useful",
    "statusDebugMessage": "bloomin 0x0000000104c2a8c0 big stacktrace of 0x0000000104cc8a3c const(bool function(immutable(char)[], scope bool delegate(ulong, scope immutable(char)[][]))) vibe.http.router.MatchTree!(vibe.http.router.Route).MatchTree.doMatch + 272\n18 meaningless drivel 0xffffffffffffffff 0x0 + 18446744073709551615"
}

at times I've managed to get something useful from statusDebugMessage but not often. It would be handy to silence it, especially if doing a release build.

So in /vibe/web/rest.d#L1141-L1144 where it has:

res.writeJsonBody(
    [ "statusMessage": e.msg, "statusDebugMessage": sanitizeUTF8(cast(ubyte[])e.toString()) ], 
    HTTPStatus.internalServerError
    );

How about doing:

debug {
    res.writeJsonBody(
        [ "statusMessage": e.msg, "statusDebugMessage": sanitizeUTF8(cast(ubyte[])e.toString()) ], 
        HTTPStatus.internalServerError
        );
} else {
    res.writeJsonBody(
        [ "statusMessage": e.msg ], 
        HTTPStatus.internalServerError
        );
}
@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Dec 18, 2016

Member

Sounds reasonable. I would possibly have preferred testing HTTPServerSettings.options & HTTPServerOption.errorStackTraces instead, but the REST interface generator doesn't have access to that as it stands. It could still make sense to make this a runtime setting in RestInterfaceSettings, though, if there is a need.

Member

s-ludwig commented Dec 18, 2016

Sounds reasonable. I would possibly have preferred testing HTTPServerSettings.options & HTTPServerOption.errorStackTraces instead, but the REST interface generator doesn't have access to that as it stands. It could still make sense to make this a runtime setting in RestInterfaceSettings, though, if there is a need.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment