Repository navigation
Feature Request: Bearer Auth - allow custom error response content type #5218
Description
Activity
- changed the title
[-]Feature Request: Bearer Auth - allow custom error response content type (e.g. `application/problem+json`)[/-][+]Feature Request: Bearer Auth - allow custom error response content type[/+]on Aug 12, 2026 Just learnt about RFC 9457 and thought it was pretty cool! I think it'd be really helpful to see first class support for
application/problem+jsonin Hono, especially its strong type inference around request/response types and RPC. I'd definitely use this in our production environments 👍🏼This might be in consideration for this v5 comment #5106 (comment)
Hi @max-got
Thank you for the request. I think the middleware should allow users to set error responses flexibly. Letting
MessageFunctionreturnResponseis one of the solutions, but we have to consider.If it doesn't introduce a breaking change, we can include it in a minor version update. Don't need to include v5.
Reacted by Max G. and John Emerson RequizoOpened http://github.com/honojs/hono/pull/ so
messagecan return aResponse(RFC 9457) without breaking existing string/object messages.
What is the feature you are proposing?
Problem
Bearer auth error responses can't be sent as anything other than
application/jsonortext/plain. The content type is hardcoded inthrowHTTPException...Request
Since we want to adhere to RFC 9457 problem details (
application/problem+json) everywhere, it would be nice if we are able to customize the content type in the response. Since the middleware throws anHTTPExceptionwith a pre-builtres, anonErrorhandler can't fix the headers afterwards either. See for Reference bearer-auth/index.tsIdea
Let
MessageFunctionalso return aResponseand use it as-is (setWWW-Authenticateif missing). Backwards compatible. Alternatively acontentTypeoption next tomessage(?)Current workaround: throw from the message function and rebuild the
WWW-Authenticateheader manually in the app.