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
For now this is my workaround, which relies on the errors thrown or passed to next having a valid headers property, and feels a bit hacky:
app.use((err, req, res, next) => {
if (err.headers && (typeof err.headers === 'object')) {
for (let [key, val] of Object.entries(err.headers)) {
res.header(key, val);
}
}
next(err);
});
app.use(HttpProblemResponse({strategy}));
I think it would be better if we could somehow explicitly include response headers when mapping specific error types, such that those headers are then set on the response sent by HttpProblemDetailsMiddleware().
The text was updated successfully, but these errors were encountered:
There are cases where I would like to set additional headers on a problem details response. For example:
WWW-Authenticate
header (https://datatracker.ietf.org/doc/html/rfc6750#section-3)Retry-After
header (which is mentioned at https://www.rfc-editor.org/rfc/rfc7807#section-4) and alsoX-RateLimit-Remaining
, etc.For now this is my workaround, which relies on the errors thrown or passed to
next
having a validheaders
property, and feels a bit hacky:I think it would be better if we could somehow explicitly include response headers when mapping specific error types, such that those headers are then set on the response sent by
HttpProblemDetailsMiddleware()
.The text was updated successfully, but these errors were encountered: