Description
Task List
- Steps to reproduce provided
- Stacktrace (if present) provided
- Example that reproduces the problem uploaded to Github
- Full description of the issue provided (see below)
Description
Take an armpit rolled server which provides no Content-type header although responses bodies are correct json payloads. We had this with a heavily customized Magento1 instance recently.
In that case Micronaut falsely complains the body is empty which is a source of confusion at the very least.
The reason is the Micronaut client has no clue as of how to decode the response without a content-type, so the resulting decoded object ends up empty, which is the reason for the exception message.
The exception should be triggered upfront as soon as it's seen there is no suitable decoder for a given payload.
Or maybe have a way to specify a "fallback" content-type.
Workarounds: ask the server maintainers to return a content-type (which was not possible in our case)
or retrieve as String and decode by hand with Jackson. Yay.
Steps to Reproduce
- Checkout https://github.com/fabmars/no-content-type-issue
- Run /server/server-bad.sh which fires up a custom nginx which never returns any content-type header.
- Run NoContentTypeTest unit test
You may also reproduce those steps using /server/server-good.json for a "nominal" behavior (with a content-type)
Expected Behaviour
At the very least a consistent HttpClientResponseException message (eg: "unable to decode body for content type {}")
Or a fallback (to decoding application/json for example)
Actual Behaviour
HttpClientResponseException with misleading "Empty body" message.
Environment Information
- Operating System: Ubuntu 20.04
- Micronaut Version: 2.2.0 and 1.3.7
- JDK Version: 1.8
Example Application
https://github.com/fabmars/no-content-type-issue