You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In roaster 1.0.0 when an error gets triggered, this is always json and in rare cases xml regardless of the Accept header in the client request. This is due to two things:
The code usually works with map objects and conversion to xml is not defined from there
The code just implements json in various places e.g. in router:default-error-handler
For this reason we set up our own x-error-handler, which does a second thing: when the error is a client error, we don't return module|line|column because the client would not be interested in that part. For server errors we obviously have something going on we actually need to look at on the server and thus we include those.
We explicitly call roaster:response with head(roaster:accepted-content-types()) to have the biggest chance for the right response type. Note that roaster:get-content-type-for-code() would have been better, but that function is still in the router module.
let $responsecode := errors:get-status-code-from-error($errmap?code)
returnroaster:response($responsecode, head(roaster:accepted-content-types()),
<error>
<code>{$errmap?code}</code>
<description>{$errmap?description}</description>
{
if ($responsecode lt500) then () else (
<module>{$errmap?module}</module>,
<line>{$errmap?line}</line>,
<column>{$errmap?column}</column>
)
}
</error>
)
The text was updated successfully, but these errors were encountered:
In roaster 1.0.0 when an error gets triggered, this is always json and in rare cases xml regardless of the Accept header in the client request. This is due to two things:
router:default-error-handler
For this reason we set up our own x-error-handler, which does a second thing: when the error is a client error, we don't return module|line|column because the client would not be interested in that part. For server errors we obviously have something going on we actually need to look at on the server and thus we include those.
We explicitly call
roaster:response
withhead(roaster:accepted-content-types())
to have the biggest chance for the right response type. Note thatroaster:get-content-type-for-code()
would have been better, but that function is still in the router module.The text was updated successfully, but these errors were encountered: